Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 6 123 ... LastLast
Results 1 to 10 of 59

Thread: iPeng and YT

  1. #1
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,767

    iPeng and YT

    I was trying to fix YT plugin for the issue with iPeng (and I think other controllers like Orange squeeze) where, once you've done a search if you press a track, it brings a context menu but quite often it plays something random. You have to long-press the item to get the same context menu and then play the right track. I've added 2 logs that basically show the same item being pressed and long-pressed.

    The long story short seems to be that, when long-pressed, the context menu I receive has, assuming that the 1 level menu was a search for "toto" and we selected item 36 from the result.

    "item_id:2_toto.36",

    This is fine as then LMS will redo a search with parameter "toto" and ask for item 36

    But when short-pressed, all I got is

    "item_id:2.36",

    The query parameter is gone and of course, when I do a YT API call, that cannot return the correct result

    I understand that the difference between short press and long press is related to playlist play and destructive mode, but I don't understand why the parameter of the query is lost (and it does not seem to be an iPeng problem, I've seen others having the same issue with Orange squeeze.

    As far as I understand, LMS gets context menu by storing Level, Search and Index using that "." and "_" syntax, but I don't know much more
    Attached Files Attached Files
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  2. #2
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    14,378
    It has nothing to do with the long vs. short press, these are two different menu definitions right from the beginning.
    I suspect there’s something wrong with that first menu you create, maybe you create it too early and if you do it a second time cached data comes in or something.
    ---
    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

  3. #3
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,767
    Quote Originally Posted by pippin View Post
    It has nothing to do with the long vs. short press, these are two different menu definitions right from the beginning.
    I suspect there’s something wrong with that first menu you create, maybe you create it too early and if you do it a second time cached data comes in or something.
    I don't know, I should probably have said "pressure" press vs "normal" press. The result is 100% reproducible. It seems to me that in the cometd log, these are 2 different contextmenu created, no? And I have these 2 different menus by either pressure press or normal press. There is that item "touchToPlaySingle:1", so I assumed it meant "just play that item" and in this case it always works, but when it's trying to load a playlist and then play item "N", it fails as the "search" parameter is lost

    [edit]: this code is above my paygrade, but it really seems that when it does not receive a "touchtoplay" option, then LMS does not build properly the breadcrumbs to retrieved the query (see XMLBrowser.pm) and then provides a non-valid context to its client (iPeng)

    [edit2]: I've been extensively through the browsing code (I've added here a log that combines cometd and browse and here what's happening is clearer). What I still don't understand is that is this an issue in the way LMS handles subfeeds that are URL (the suppression of the search argument when the subfeed replaces its parent), is this a problem with the way iPeng asks LMS to play once it has received the answer to the 1st request, or is this something wrong in my items ... don't know.

    As a summary, what's in that log

    - in iPeng, I did a query for videos with search key 'essai' and then I asked to play item n°7 (non-destructive play)
    - iPeng asks for subitems 0..99 of menu item 2 which contains a search for "essai" and set for xmlbrowserPlayControl at 7
    - iPeng
    - LMS does the query and gets the 100 items and "replaces" elements under menu item 2 with the 100 items
    - LMS returns a reponse to iPeng with item_id 2.7 (*not* 2_essai.7)
    - iPeng asks LMS to play playlist with item_id 2.7
    - LMS does a query to YT with no search key ... and plays whatever comes back at offset 7

    The reason why it works with destructive play or when current playlist is empty is because the query made by iPeng is different
    Attached Files Attached Files
    Last edited by philippe_44; 2018-01-07 at 00:43.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  4. #4
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    14,378
    Could you please post the original menu log (including the search query) for a menu that works.
    ---
    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

  5. #5
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    14,378
    Your last log doesn’t contain any menu definition, just the context menu.
    As long as I can’t see the difference in the original menus I can’t really say anything g about what’s wrong.

    iPeng usually should not modify the ids or parameters unless you are supplying tagged parameters (but that would only be in menu items with text input or buttons or the like) so the difference must be explainable somehow from the original menu code.
    ---
    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

  6. #6
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    14,378
    And one more thing I find: is this really network.cometd logging with iPeng?
    I find these menus very different from the ones I see, the lack all the base menu definitions that are usually there, it’s just the raw items.
    But menu queries join any base definitions with the parameters in the items so this is not very telling.
    ---
    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

  7. #7
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,767
    Quote Originally Posted by pippin View Post
    And one more thing I find: is this really network.cometd logging with iPeng?
    I find these menus very different from the ones I see, the lack all the base menu definitions that are usually there, it’s just the raw items.
    But menu queries join any base definitions with the parameters in the items so this is not very telling.
    Here is a full log of a working example, from the initial search to the working playback

    [edit]: yes, this is iPeng and network.cometd log with it. But the previous logs started at the press on the item I wanted to play - everything before (search) was removed
    Attached Files Attached Files
    Last edited by philippe_44; 2018-01-07 at 10:48.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  8. #8
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    14,378
    OK, a few observations after running down what iPeng does here:

    1. I'm still a bit confused by your terminology. You talk about "non-destructive play". I don't know what that is. "play" is always "destructive" in my system, it clears the current playlist and then plays a single track or album or whatever you have selected.
    In addition there is "add to end" or "add next"/"play next" which adds a track or album somewhere within the current playlist ("play next" in iPeng is different to the default LMS behavior in that it will also start playback and skip to the next track if a player currently is not playing but that has nothing to do with this command level and is being handled separately.

    There's also the "defeat destructive TTP" option in LMS which iPeng ignores because it has it's own logic around this but which might have an influence on how play commands are being built by LMS, this might be the source of confusion on why this is never a problem for me while it seems to be one for you.

    2. Here's how these type of menus work (this is what is in the menu definition JSON code in the logs):
    • Each menu has a set of base definitions for a number of actions. These are optional, the complete actions could also be supplied for each individual menu item but in the XMLBrowser menus that's not what happens, they have the default items. These default actions lack a full parameter set to work, these parameters are then supplied with each individual menu item.
    • Actions can be for example "go" (to open a submenu, the default action if present), "do" (to do an action; also a default, usually EITHER of "do" or "go" is supplied but never both) and "more" to open a context menu.
    • For playable items there are special actions to play this item. They are called "play", "add", "add-hold" corresponding to the button mapping on the Squeezebox Controller. These are the actions used by iPeng for its play commands in playlists (the "play", "add to end" and "play next" commands).


    3. Now ... there's one thing in iPeng that's special: whenever you single-tap a playable item outside an album or playlist and the menu definition says you should just "play" it won't (because the user can't see that this will immediately play) but instead it will show an intermediate context menu.
    This intermediate context menu you get when short-tapping the item is NOT the normal context menu retrieved through the "more" action but it's just a collection of the actions supplied for the item you selected. iPeng takes the "play", "add",.... actions and builds a menu from them. If you then tap one of these items it will just issue the action you selected, just like if you had pressed the respective button on the Squeezebox Controller (or the Radio).

    4. If you long-press on an item, OTOH, iPeng will issue the "more"-action to get a full context menu which typically can contain additional items like metadata information etc. Only if no "more" action is being provided will iPeng also revert to the self-made menu as in 3.

    Now .. what you seem to see (and I don't) is that the actions from the menu under 3. don't work. This might have to do with the definition in your menu and maybe with the "destructive TTP" setting because I really can't reproduce this issue (in my setup, the "inhibit destructive TTP" setting is off).
    IMHO this means something is wrong with the menus provided by your plugin or what XMLBrowser makes out of your information, the context menu seems to work, though, if I understand you correctly.
    ---
    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

  9. #9
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,767
    Quote Originally Posted by pippin View Post
    OK, a few observations after running down what iPeng does here:

    1. I'm still a bit confused by your terminology. You talk about "non-destructive play". I don't know what that is. "play" is always "destructive" in my system, it clears the current playlist and then plays a single track or album or whatever you have selected.
    In addition there is "add to end" or "add next"/"play next" which adds a track or album somewhere within the current playlist ("play next" in iPeng is different to the default LMS behavior in that it will also start playback and skip to the next track if a player currently is not playing but that has nothing to do with this command level and is being handled separately.
    I'm not sure about my ... terminology - I'l try to get that right. What I observe is different in term of what is sent to LMS if I short or long/hard press an item in a list that YT has returned to iPeng. Visually, it is the *same* menu with "share", play all", "play at the end", "player after"and "play" (sorry a quick translation from French) but the query that is sent to LMS is different, depending if there is something playing or not - I think this is what you describe in 3.

    There's also the "defeat destructive TTP" option in LMS which iPeng ignores because it has it's own logic around this but which might have an influence on how play commands are being built by LMS, this might be the source of confusion on why this is never a problem for me while it seems to be one for you.
    I will try that

    3. Now ... there's one thing in iPeng that's special: whenever you single-tap a playable item outside an album or playlist and the menu definition says you should just "play" it won't (because the user can't see that this will immediately play) but instead it will show an intermediate context menu.
    This intermediate context menu you get when short-tapping the item is NOT the normal context menu retrieved through the "more" action but it's just a collection of the actions supplied for the item you selected. iPeng takes the "play", "add",.... actions and builds a menu from them. If you then tap one of these items it will just issue the action you selected, just like if you had pressed the respective button on the Squeezebox Controller (or the Radio).

    4. If you long-press on an item, OTOH, iPeng will issue the "more"-action to get a full context menu which typically can contain additional items like metadata information etc. Only if no "more" action is being provided will iPeng also revert to the self-made menu as in 3.
    Which is what I see, reverting to 3. but what is sent to LMS is different on long press or short-press-with-items-playing

    Now .. what you seem to see (and I don't) is that the actions from the menu under 3. don't work. This might have to do with the definition in your menu and maybe with the "destructive TTP" setting because I really can't reproduce this issue (in my setup, the "inhibit destructive TTP" setting is off).
    IMHO this means something is wrong with the menus provided by your plugin or what XMLBrowser makes out of your information, the context menu seems to work, though, if I understand you correctly.
    It's not that they don't work but the query sent to YT is wrong when LMS returns you a contextmenu. The item_id are something like X.Y and not X_query.Y. And it does that when it has received a query from iPeng like
    Code:
    [18-01-07 17:13:36.8923] Slim::Control::XMLBrowser::cliQuery (47) {
      _index => 0,
      _quantity => 100,
      cachesearch => 1,
      item_id => 2,
      menu => "youtube",
      search => "essai",
      useContextMenu => 1,
      userInterfaceIdiom => "iPeng",
      "xmlbrowserPlayControl" => 14,		
    }
    The problem seems to be the use of xmlBrowerPlayControl. When receiving a query with xmlbrowserPlayControl, XMLBrowser will not build a contextmenu that uses crumbs (and search info that was sent), but it will simply add the xmlBrowserPlayControl to the item level, so in the case of my example, it is 2.14. You can see that around line 800 of XMLBrowse.pm and look as well at _playlistControlContextMenu (around line 1790)
    See below such "wrong" context menu data (see 2.14 for item_id)
    Code:
      {
        channel => "/a43366c3/slim/request",
        data => {
              count     => 3,
              item_loop => [
                             {
                               actions => {
                                            go => {
                                                    cmd => ["youtube", "playlist", "add"],
                                                    nextWindow => "parentNoRefresh",
                                                    params => { item_id => "2.14", menu => 1 },
                                                    player => 0,
                                                  },
                                          },
                               style   => "item_add",
                               text    => "Ajouter \xE0 la fin",
                             },
                             {
                               actions => {
                                            go => {
                                                    cmd => ["youtube", "playlist", "insert"],
                                                    nextWindow => "parentNoRefresh",
                                                    params => { item_id => "2.14", menu => 1 },
                                                    player => 0,
                                                  },
                                          },
                               style   => "item_insert",
                               text    => "Lire \xE0 la suite",
                             },
                             {
                               actions => {
                                            go => {
                                                    cmd => ["youtube", "playlist", "play"],
                                                    nextWindow => "nowPlaying",
                                                    params => { item_id => "2.14", menu => 1 },
                                                    player => 0,
                                                  },
                                          },
                               style   => "item_play",
                               text    => "Lecture",
                             },
                           ],
              offset    => 0,
              window    => { windowStyle => "text_list" },
            },
        ext => { priority => "" },
        id => 144,
      },
    ]
    So when you send a "play" (one of the potential actions), then the params are wrong, they are missing the search value (essai in my case).

    So I don't know if the issue is that XMLBrowse should add the crumbs to the item_id or if the xmlbrowserPlayControl should contain it at first, or something else

    But when xmlbrowserPlayControl is not used by iPeng (which is the case for short press or when nothing plays) then the query sent to XMLBrowse makes it rebuild by himself the crumbs so the context menu is then valid

    Hope this helps

    [edit]: see a working query
    Code:
    [18-01-07 19:42:25.2815] Slim::Control::XMLBrowser::cliQuery (47) {
      _index => 0,
      _quantity => 100,
      isContextMenu => 1,
      item_id => "2_essai.2",
      menu => "youtube",
      touchToPlay => "2_essai.2",
      touchToPlaySingle => 1,
      xmlBrowseInterimCM => 1,
    }
    and its reponse
    Code:
    {
        channel => "/2d9910f5/slim/request",
        data => {
              count     => 5,
              item_loop => [
                             {
                               actions => {
                                            go => {
                                                    cmd => ["youtube", "playlist", "add"],
                                                    nextWindow => "parentNoRefresh",
                                                    params => { item_id => "2_essai.2", menu => 1 },
                                                    player => 0,
                                                  },
                                          },
                               style   => "item_add",
                               text    => "Ajouter \xE0 la fin",
                             },
                             {
                               actions => {
                                            go => {
                                                    cmd => ["youtube", "playlist", "insert"],
                                                    nextWindow => "parentNoRefresh",
                                                    params => { item_id => "2_essai.2", menu => 1 },
                                                    player => 0,
                                                  },
                                          },
                               style   => "item_insert",
                               text    => "Lire \xE0 la suite",
                             },
                             {
                               actions => {
                                            go => {
                                                    cmd => ["youtube", "playlist", "play"],
                                                    nextWindow => "nowPlaying",
                                                    params => { item_id => "2_essai.2", menu => 1 },
                                                    player => 0,
                                                  },
                                          },
                               style   => "item_play",
                               text    => "Lecture",
                             },
            },
        ext => { priority => "" },
        id => 1501,
      },
    Last edited by philippe_44; 2018-01-07 at 20:45.

  10. #10
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    1,549
    I see the same issue with Orange Squeeze. I have "inhibit destructive TTP" set to "always ask" if that gives any more clues.

    Sent from my SM-G900F using Tapatalk

Posting Permissions

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