Home of the Squeezebox™ & Transporter® network music players.
Page 5 of 5 FirstFirst ... 345
Results 41 to 44 of 44
  1. #41
    Slim Devices Developer fcm4711's Avatar
    Join Date
    Apr 2005
    Hey pippin

    Ok, thanks for checking. I moved it to my regular repository: http://www.gwendesign.com/sc/repo/repo.xml

    Programming is the art of cleverly arranging bits and bytes. - (c) Felix Mueller

  2. #42
    Quote Originally Posted by pippin View Post
    OK, works for me.

    I've added a documentation bug on this to have it included in the CLI doc:

    Chris, Peter, Felix, could you have a look at this?
    Thanks for opening the bug. I think we mainly want 2 things changed in SBS (and maybe the MySB code, too)
    1) implement a do-nothing stub routine for getexternalvolumeinfo
    2) document the way it's supposed to work

    But is that the best way to do this? I'd like to propose another slight change that I think is inline with what we've been doing. SBS has global notifications, right? Notifications without specific players?

    How about

    1) the SBS code's core implementation of getexternalvolumeinfo does nothing beyond sending a *global* getexternalvolumeinfo notification with *no tagged parameters*.
    2) SBS *plugins* could then choose either to intercept the getexternalvolumeinfo command as we have done *or* subscribe to getexternalvolumeinfo notifications. If a plugin subscribed to getexternalvolumeinfo notifications, it would turn around and send player-specific getexternalvolumeinfo notifications with tagged parameters for any players where it's appropriate

    This would be 100% compatible with the code Chris, Felix, and I have added and provide two new benefits:

    1) Plugins would not need to intercept getexternalvolumeinfo, and if they chose not to intercept getexternalvolumeinfo, there would be a lower chance of anything going wrong. With our current setup, there's a risk that a bug in one plugin might prevent if from chaining the next implementation of getexternalvolumeinfo.
    2) Applets could send information. For instance, there might be applet implementations of any of our three plugins for use on SB Touch -- perhaps using its USB port for the RS232 comms for DenonSerial. If the core SBS (and MySB??) code sent "empty"/global getexternalvolumeinfo notifications, then even an applet could see when a control app like iPeng wanted getexternalvolumeinfo info, and could provide that information.

    Sound right?
    owner of the stuff at https://tuxreborn.netlify.app/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

  3. #43
    Senior Member pippin's Avatar
    Join Date
    Oct 2007

    Re: Adding a player parameter

    Sounds right.
    Could you add that to the bug?
    learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
    Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
    at penguinlovesmusic.com
    New: iPeng 9, the Universal App for iPhone, iPad and Apple Watch

  4. #44
    Senior Member Aesculus's Avatar
    Join Date
    Jan 2008

    Is this still necessary?

    I am trying to determine if this issue of registering external volume controls devices is even necessary anymore. I commented out the sub getexternalvolumeinfoCLI and iPeng and Squeezer still seem to work just fine controlling a 100% volume SB Touch device.

    I am trying to eliminate an error I reported up thread (useIxHashes) that seems to be evasive for everyone. It happens when this routine is called and only in iPeng, since that is the only app that I think supports it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts