Home of the Squeezebox™ & Transporter® network music players.
Page 100 of 102 FirstFirst ... 50909899100101102 LastLast
Results 991 to 1,000 of 1020
  1. #991
    Senior Member philchillbill's Avatar
    Join Date
    Jan 2019
    Location
    The Netherlands
    Posts
    820

  2. #992
    Senior Member
    Join Date
    Aug 2006
    Posts
    255
    Quote Originally Posted by philchillbill View Post
    MediaServer's handling of favorites has been extensively re-written to improve the user-experience with nested hierarchies. The call-out of ordinal numbering while listing favorite names was removed as it adds little value. Folder names are likewise no longer called-out, as they are not in themselves playable audio items.

    In the past, MediaServer always retrieved all your favorites recursively from LMS before processing anything further. From now on, a fuzzy-match is attempted at each retrieved level and further retrieval stops upon a match. Top-level items therefore play/stream much quicker.

    To assist with handling very deep nesting levels, the DOT notation now fudges a favorite ID for XMLbrowser after retrieving the base-item ID from the top level of the hierarchy. This makes it possible to play favorites at any depth without timeouts, provided you can figure out from looking at the LMS GUI (default skin!) what the numbers between the dots should actually be It's better than failure!

    Here's a summary of the 4 ways to play/stream favorites:

    [NAME] 'Play favorite "Jazz FM"' — looks for a (fuzzy) match by name. Although all hierarchical levels will be traversed if necessary, an early match now stops unnecessary further recursion.

    [NUMBER] 'Play favorite number 6' / 'Play my sixth favorite' — plays a favorite from any hierarchical level, based on its position in the overall flattened hierarchy. Useful if the favorite-name is long/unwieldy or Alexa regularly misunderstands it.

    [ITEM] 'Play favorite: folder "Podcasts", item 4' — plays a favorite within a named folder, denoted by the favorite's numbered position within that folder. Useful for targeting e.g. episodes by number when you cannot remember their names.

    [DOT] 'Play favorite 5 dot 1 dot 6' — if you have a lot of favorites and Alexa always times out before your hierarchy is traversed, this notation can be used as a fallback to successfully play deeply-nested favorites. It does not request the whole hierarchy from LMS, just the base level (for the volatile ID #) and then the favorite itself directly.

    When it comes to listing favorites, there are 3 approaches:

    'List my favorites' — lists all playable audio favorites at any depth, skipping folder names found along the way. The whole nested favorites-hierarchy is effectively flattened to mention only playable-audio entries.

    List level 2 favorites' / 'List second level favorites' — mentions all favorites at that level of hierarchy, even if in different parent folders along the way. Level is level!

    'List favorites in folder "Radio"' — list playable entries in that named folder, no matter how deep 'Radio' lies in the overall hierarchy.

    Enjoy!
    My favourites consist of 4 folders with the 4th folder containing 4 subfolders. When I ask MS on an echo show to list level 2 favourites, it correctly lists the contents of the first 3 folders by showing each folder and its contents in succession. A level 3 request results in the contents of the the 4th folder's subfolders and contents being listed as expected. My problem is when I request an item using the "dot" notation [e.g. Stream favourite 2 (level No.)dot 3 (level item No.)], I get an error that says the device can't determine the base ID to apply to the dotted notation. In the quoted post you also talk about a base ID which I don't understand what this is in my file structure. Just to note, the dot notation did work for me when the folders were part of the listings e.g. "Stream favourite 4 dot 2 dot 5" played the 5th item in the 2nd subfolder of folder No. 4. That 4th folder has a lot of German names and the dot notation was a neat way of getting around me trying to murder
    the German language ;-) I can of course access all items using their item number alone, but I would like to figure out the dot level approach.

  3. #993
    Senior Member philchillbill's Avatar
    Join Date
    Jan 2019
    Location
    The Netherlands
    Posts
    820
    Quote Originally Posted by raglencross;
    My favourites consist of 4 folders with the 4th folder containing 4 subfolders. When I ask MS on an echo show to list level 2 favourites, it correctly lists the contents of the first 3 folders by showing each folder and its contents in succession. A level 3 request results in the contents of the the 4th folder's subfolders and contents being listed as expected. My problem is when I request an item using the "dot" notation [e.g. Stream favourite 2 (level No.)dot 3 (level item No.)], I get an error that says the device can't determine the base ID to apply to the dotted notation. In the quoted post you also talk about a base ID which I don't understand what this is in my file structure. Just to note, the dot notation did work for me when the folders were part of the listings e.g. "Stream favourite 4 dot 2 dot 5" played the 5th item in the 2nd subfolder of folder No. 4. That 4th folder has a lot of German names and the dot notation was a neat way of getting around me trying to murder
    the German language ;-) I can of course access all items using their item number alone, but I would like to figure out the dot level approach.
    The base-ID is not an end-user's concern, it's mine. Favorites in LMS are more like a plugin-thing than a built-in. They have to be queried/controlled via LMS' XML Browser which is basically like parsing the UI's menu structure and figuring out which sub-item to select. Very unlike control for e.g. songs/albums/genres/playlists. Every time I call up XML Browser, it uses a different set of ephemeral IDs for everything, but the dotted sub-parts remains the same. The base ID changes on every call so it has to be figured out each time (unfortunately). It's like SeaSide-FM is 1fbd2fed.2.3 now but e2b431ac.2.3 next time. Etc. Without the base-ID I cannot apply the correct dotted sub-ID to play it.

    Playing via dot notation used to first request all the favorites (which was fine if your internet and LMS server are fast). Then the whole ID is just there every time and nothing has to be fudged. I decided to change it because lots of people have problems with nested favorites due to slow internet or LMS. By just requesting the top level favorites and not recursing, I can figure out what the ID of a sub-favorite would be by fudging. And so the theory goes

    I have not yet figured out why your LMS is not returning a base-ID that I can discern. In my testing (with v8.3) it always worked just fine. What LMS version are you on? I've added some debug lines to the code so if you could please try a few more commands that result in the base-ID error I can take a deeper look.

    The dotted notation indeed used to include the position of folder names in the hierarchy but I took that out. If you want to figure out the new dotted notation, just skip folders when counting at each level. If that's a pain I can put the folders back in. Having them in makes listing favorites longer than needed but probably would not be a negative thing for playing/streaming. Would it be confusing if they were not mentioned during listing but needed to be counted when playing? Thoughts?


    EDIT: In retrospect, the folder names should still be counted when using the dot notation, so nothing has actually changed in that respect.
    The issue seems to be that sometimes, LMS is returning a very different structure to the initial ["favorites", "items", 0, 1000, "menu:favorites", "menu:1"] request, which is odd to say the least
    Last edited by philchillbill; 2021-09-01 at 14:34.

  4. #994
    Senior Member
    Join Date
    Aug 2006
    Posts
    255
    Quote Originally Posted by philchillbill View Post
    The base-ID is not an end-user's concern, it's mine. Favorites in LMS are more like a plugin-thing than a built-in. They have to be queried/controlled via LMS' XML Browser which is basically like parsing the UI's menu structure and figuring out which sub-item to select. Very unlike control for e.g. songs/albums/genres/playlists. Every time I call up XML Browser, it uses a different set of ephemeral IDs for everything, but the dotted sub-parts remains the same. The base ID changes on every call so it has to be figured out each time (unfortunately). It's like SeaSide-FM is 1fbd2fed.2.3 now but e2b431ac.2.3 next time. Etc. Without the base-ID I cannot apply the correct dotted sub-ID to play it.

    Playing via dot notation used to first request all the favorites (which was fine if your internet and LMS server are fast). Then the whole ID is just there every time and nothing has to be fudged. I decided to change it because lots of people have problems with nested favorites due to slow internet or LMS. By just requesting the top level favorites and not recursing, I can figure out what the ID of a sub-favorite would be by fudging. And so the theory goes

    I have not yet figured out why your LMS is not returning a base-ID that I can discern. In my testing (with v8.3) it always worked just fine. What LMS version are you on? I've added some debug lines to the code so if you could please try a few more commands that result in the base-ID error I can take a deeper look.

    The dotted notation indeed used to include the position of folder names in the hierarchy but I took that out. If you want to figure out the new dotted notation, just skip folders when counting at each level. If that's a pain I can put the folders back in. Having them in makes listing favorites longer than needed but probably would not be a negative thing for playing/streaming. Would it be confusing if they were not mentioned during listing but needed to be counted when playing? Thoughts?


    EDIT: In retrospect, the folder names should still be counted when using the dot notation, so nothing has actually changed in that respect.
    The issue seems to be that sometimes, LMS is returning a very different structure to the initial ["favorites", "items", 0, 1000, "menu:favorites", "menu:1"] request, which is odd to say the least
    Thanks, Phil, for looking into this. I am using LMS v8.2 on a RPi 4 with the Raspian OS.

    At approximately 11:20 am ADT, I attempted to play/stream a few items using the dot notation, as you requested, and got the base-ID error. Hopefully, you can now catch this with your additional debug code.

    I get what you are trying to do with the changes, but with 84 favourites organized in 4 folders (one with subfolders), and a middling internet speed (20-30 Mbps), I was having no problems retrieving content. I especially liked using the dot method based on the folder and subfolder numbers, probably because of years of conditioning using this file structure on OS's from DOS through to Linux.

    Just to clarify, previously the top level folders were listed first and then their contents. Next, the subfolders were listed, followed by their contents. Folders, subfolders and contents were all numbered. In the new system, only the contents are numbered with a folder header shown on the echo show where appropriate. I do like this approach, as it is a more logical way of presenting the information in a folder structure. My vote is to stick with this approach, but reinstate the folder dot notation, if possible. I favour this over using names/sequential numbers because to my mind it is easier to access "Meisterwerke der Oper" in folder 4, subfolder 1, item 5 by saying "4 dot 1 dot 5" then remembering that it is No. "42" or, God forbid, trying to get Alexa to understand the German words
    Last edited by raglencross; 2021-09-02 at 08:24.

  5. #995
    Senior Member philchillbill's Avatar
    Join Date
    Jan 2019
    Location
    The Netherlands
    Posts
    820
    Quote Originally Posted by raglencross;
    Thanks, Phil, for looking into this. I am using LMS v8.2 on a RPi 4 with the Raspian OS.

    At approximately 11:20 am ADT, I attempted to play/stream a few items using the dot notation, as you requested, and got the base-ID error. Hopefully, you can now catch this with your additional debug code.

    I get what you are trying to do with the changes, but with 84 favourites organized in 4 folders (one with subfolders), and a middling internet speed (20-30 Mbps), I was having no problems retrieving content. I especially liked using the dot method based on the folder and subfolder numbers, probably because of years of conditioning using this file structure on OS's from DOS through to Linux.

    Just to clarify, previously the top level folders were listed first and then their contents. Next, the subfolders were listed, followed by their contents. Folders, subfolders and contents were all numbered. In the new system, only the contents are numbered with a folder header shown on the echo show where appropriate. I do like this approach, as it is a more logical way of presenting the information in a folder structure. My vote is to stick with this approach, but reinstate the folder dot notation, if possible. I favour this over using names/sequential numbers because to my mind it is easier to access "Meisterwerke der Oper" in folder 4, subfolder 1, item 5 by saying "4 dot 1 dot 5" then remembering that it is No. "42" or, God forbid, trying to get Alexa to understand the German words
    Thanks for running the tests for me and also for the feedback. I found a silly bug that was causing the error

    However, while playing around I found a much better way to handle favorites under the hood. It makes the dotted syntax play instantly with predictable IDs rather than ephemeral IDs. It also removes the need for recursion in most of the other forms of playback. If recursion is needed, the discovered favorites hierarchy is stored in so-called session-storage so that it is re-usable within the same session. If you get a favorite specification wrong then the re-attempt is much, much faster.

    I'll play with it a little more just to check on corner-cases and push it live tomorrow. But it is much more fluid in my testing so far.

  6. #996
    Senior Member philchillbill's Avatar
    Join Date
    Jan 2019
    Location
    The Netherlands
    Posts
    820
    The new favorites engine is live. The spoken commands all stay the same, it's just the way they are handled that changed.

    Playing by dot notation works directly with the supplied utterance and does not bother with ephemeral IDs any longer. A side effect of this is that if you ask to play a favorite that does not exist, the higher-order favorite that exists will play instead. In other words, if you ask to play 2 dot 3 dot 1 dot 7 and there is no fourth level of favorites in your hierarchy, item 2.3.1 would play if it existed. If not, 2.3 would play. etc. LMS just ignores rightmost invalidities in SNMP-style favorite-IDs. To figure out what numbers to use between the dots, just look at your favorites in the default skin and count both folders and audio items in the order shown to get the correct value.

    Playing by name now makes use of a search function without first retrieving all your favorites. If a search fails then — as step two — a repeated search attempt using each word in the favorite name separately is tried. For example, if you request Naim Radio, Alexa hears "Name Radio" which fails the search (LMS does not do anything Fuzzy). This is split into 2 search items, 'Name' and 'Radio'. Naim Radio will not appear in the results when 'Name' is tried but it will be included in the results for 'Radio'. The skill's fuzzy match of Name Radio against Naim Radio will work, so Naim Radio will play. If none of the searches matches outright, as a fallback your whole favorites tree is fetched recursively and then a fuzzy match is attempted against the whole actual tree. In 99% of cases, timeouts should be a thing of the past.

    Whenever all your favorites must be fetched recursively — i.e. when you list favorites, play by number, or play by folder/item — they are now held in Alexa's session storage so any subsequent command in a session simply re-uses the stored hierarchy instead of retrieving again. Remember, on Echos with screens, any command that displays APL for 30 seconds on screen creates a session in the background — successive favorites commands will now always be faster on an Echo Show!

    Enjoy!

  7. #997
    Senior Member
    Join Date
    Aug 2006
    Posts
    255
    Phil, my initial testing of your revised favourites engine has worked flawlessly with the added bonus that items appear to fetch and playback much more quickly. Keep up the good work!

  8. #998
    Senior Member
    Join Date
    Jun 2005
    Location
    The South, UK
    Posts
    361
    Quote Originally Posted by raglencross View Post
    Phil, my initial testing of your revised favourites engine has worked flawlessly with the added bonus that items appear to fetch and playback much more quickly. Keep up the good work!
    I echo that (no alexa pun intended!), a great improvement, good work!
    Location 1: LMS 8.3 on Win 10 Brix Server, x3 SB Radios, x1 Touch, x1 Controller : Location 2: LMS 8.3 on Win 10 Brix Server, x2 SB Radios, x1 Duet Receiver, x1 Controller : Alexa Mediaserver Smart Skill, Material Android, SqueezeliteX control

  9. #999
    Senior Member philchillbill's Avatar
    Join Date
    Jan 2019
    Location
    The Netherlands
    Posts
    820
    Quote Originally Posted by raglencross;
    Phil, my initial testing of your revised favourites engine has worked flawlessly with the added bonus that items appear to fetch and playback much more quickly. Keep up the good work!
    Good to hear — thanks

    As a tip, playing by dot notation in the top-level folder works faster (via e.g. '0 dot 6') than playing by number (e.g. with '#6') does. The top level is 0 as an exception — otherwise counting starts at 1.


    EDIT: Since the changes outlined in the next post, this is no longer true. All play/stream notations are now equally fast.
    Last edited by philchillbill; 2021-09-13 at 09:44.

  10. #1000
    Senior Member philchillbill's Avatar
    Join Date
    Jan 2019
    Location
    The Netherlands
    Posts
    820

    Even newer favorites engine

    While examining the LMS source code around favorites-handling, I discovered an undocumented legacy feature which allows the entire favorites hierarchy to be retrieved with a single API call.

    When the 'feedMode:1' flag is added to the ['favorites', 'items'] query, a data-structure is returned from the OPML feed which thankfully contains the full nested favorites hierarchy end even references the parser if relevant. I've now rewritten MediaServer to use this. Having all names/titles available for fuzzy-matching means that play-by-name never has to recurse. Because I can create a proper item_id from the hierarchy, all favorites can be played by item_id instead of by URL, so any favorite that needs a parser-plugin will play via that plugin automatically.

    You should notice much snappier favorites handling on large collections.

    There's a small white-lie in the above in that the contents of your 'on mysqueezebox.com' folder are never included in the first retrieval-pass and have to be deliberately fetched on a second API call. This extra retrieval causes LMS itself to have to talk to the mysb service which introduces some noticeable extra latency. You'll experience a much more fluid usability overall if you discontinue using mysb for favorites (keep it for other stuff, just kill off the favorites sync) and stay with local folders for favorites. In settings, make sure you select the option as highlighted in the screenshot below. When you then delete the 'on mysqueezebox.com' folder from your favorites it will no longer be recreated upon LMS restart. Once gone, everything will be much snappier.

    Name:  mysb.png
Views: 65
Size:  16.3 KB

    Enjoy !
    Last edited by philchillbill; 2021-09-13 at 10:48.

Tags for this Thread

Posting Permissions

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