Announcement

Collapse
No announcement yet.

Media API

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Media API

    Hi,

    Just wondering when the Media API will start to be incorporated and rolled out in HS3 so that the various plugins can be controlled through HSTouch.

    I am also curious, it mentions the Media API but will this allow control of audio and video (e.g. XBMC plugin) or will it just allow control of audio.

    Personally if it was possible, it would be great to allow media control of video collections given that plugins exist to control xbmc players etc, this would allow almost full AV control from one page of the hstouch project.

    Thanks
    HS3 PRO, Win10, WeatherXML, HSTouch, Pushover, UltraGCIR, Heaps of Jon00 Plugins, Just sold and about to move so very slim system.

    Facebook | Twitter | Flickr | Google+ | Website | YouTube

    #2
    The Media API has been a part of HS3 since it was released. Some developers have been afraid to test the waters and are waiting for our plug-ins to be modified, and we are just presently starting to get those updated for HS3. HSTouch definitely needs to be updated and that is the driver for us getting our plug-ins updated. HSTouch should be able to control devices created for the Media API, but being able to drag and drop a media API instance onto a screen in the designer and have it bring up a usable UI is not there yet. There may be some media API controls/devices that will need adjustments to make them display and work properly but most devices are quite usable with HSTouch already.

    The media API was designed to work with audio and video - basically any media including internet radio and other media. The plug-in author has to map whatever controls/media it is working with into the API.
    Regards,

    Rick Tinker (a.k.a. "Tink")

    Comment


      #3
      Originally posted by Rick Tinker View Post
      The Media API has been a part of HS3 since it was released. Some developers have been afraid to test the waters and are waiting for our plug-ins to be modified, and we are just presently starting to get those updated for HS3. HSTouch definitely needs to be updated and that is the driver for us getting our plug-ins updated.
      I'm not afraid to test the waters , but how can I use/test the Media API (and more precisely the media library part) if HSTouch is not ready for it?

      Comment


        #4
        Originally posted by spud View Post
        I'm not afraid to test the waters , but how can I use/test the Media API (and more precisely the media library part) if HSTouch is not ready for it?
        Same here.. two PI waiting

        Comment


          #5
          Originally posted by spud View Post
          I'm not afraid to test the waters , but how can I use/test the Media API (and more precisely the media library part) if HSTouch is not ready for it?
          ANY plug-in can use the Media API to find and render a UI for a media plug-in, so it doesn't have to be HSTouch. However, just like I did with the thermostat API years ago, I could write a script that interrogates the devices to see if all of the relationships and information is right (or appears right). But, we also cannot fix HSTouch issues until we have a media plug-in to test with, so don't try to win the game of hurry up and wait! ;-) We are working on ours now but you don't have to wait for us.
          Regards,

          Rick Tinker (a.k.a. "Tink")

          Comment


            #6
            Originally posted by Rick Tinker View Post
            so don't try to win the game of hurry up and wait! ;-) We are working on ours now but you don't have to wait for us.



            Originally posted by Rick Tinker View Post
            ANY plug-in can use the Media API to find and render a UI for a media plug-in, so it doesn't have to be HSTouch.
            I already have one, which is a lot simpler

            Comment


              #7
              With the HSTouch implementation of (any) plugin that supports the Media API, are you going to support multizones, but in the form of a drop-down like selector. It would be great to be able to pick a drop down box that is for which player the user wants to control and be able to do that from one screen or have the option of having seperate screens for each device (but the key is having the option).

              I know some users have already (to my knowledge) implemented the Media API in their plugins, and some also have UI's that are already up and running but it would be great to have a native hstouch program that is fully integrated rather than having an embedded webpage or some other option which may be harder to use on a phone than a tablet specifically.

              I look forward to giving it a go when it is all up and running, I must say whilst there is always room for improvement, the latest HSTouch (Android) client is a huge step in the right direction, so keep it coming and I am sure there will be many happy users
              HS3 PRO, Win10, WeatherXML, HSTouch, Pushover, UltraGCIR, Heaps of Jon00 Plugins, Just sold and about to move so very slim system.

              Facebook | Twitter | Flickr | Google+ | Website | YouTube

              Comment


                #8
                I tested the water with the Squeezebox plug-in, partially used the API for the built-in media browser web page/media browser in actions but had to built extensions/revisions. The primary issue is that for multiple media sources / libraries (streaming especially such as Internet Radios, Pandora, Spotify, etc), I needed a hierarchical tree structure organization and APIs to navigate the tree, rather than having the media library as a whole with genre/artist/album filters. The second issue is that I could not efficiently implement some of the count APIs with the above mentioned media libraries/sources. This as well as other suggested revisions had been communicated to Rich/Rick earlier this year.

                Comment


                  #9
                  It is a myth that genre/artist/album/track is NOT a hierarchy. It is a complete hierarchy and works just FINE with literally any media out there. I did agree to make the "labels" configurable, which may or may not be fully completed yet - I have to look back at the code and see where I left it - but there has to be SOME hierarchy and regardless of what the labels say, it can be used and it does work. Each media collection is a set of media titles that fit into that hierarchy whether the first level of the hierarchy is called Genre or Band (e.g. AM, FM, XM) or Venue, or something else. The API calls for four levels of hierarchy and that is what is provided.

                  Each media collection is identified with information describing it as a "library" or "collection" with entries that fit into the hierarchy above.
                  Regards,

                  Rick Tinker (a.k.a. "Tink")

                  Comment


                    #10
                    I agree that genre/artist/album/track (or whatever the labels are level 1/level 2/level 3/level 4, etc with varying depth per library & branch of the hierarchy tree) can be a hierarchy if the APIs & UI workflow navigates/walks the hierarchy tree as such. If the APIs & UI workflow let's you say return tracks (or count, or entries 25 to 50, etc) at level 4 for level 3 = x and for all level 1 & level 2 it is not (what I am looking for) and is where I had to draw the line for some media libraries.

                    Comment


                      #11
                      Originally posted by pcp View Post
                      I agree that genre/artist/album/track (or whatever the labels are level 1/level 2/level 3/level 4, etc with varying depth per library & branch of the hierarchy tree) can be a hierarchy if the APIs & UI workflow navigates/walks the hierarchy tree as such. If the APIs & UI workflow let's you say return tracks (or count, or entries 25 to 50, etc) at level 4 for level 3 = x and for all level 1 & level 2 it is not (what I am looking for) and is where I had to draw the line for some media libraries.
                      You might have to give me a SIMPLE example as I cannot quite be sure it works the way you are saying is good or bad.

                      Each level is a filter, which further reduces the entries at the next level.

                      You select all genres, and you get 1000 artists. You select 2 out of 5 genres, and you get 500 artists that have entries in those 2 genres.

                      You select all 500 artists and you get 300 albums. You select 1 artist and you get 4 albums that match that artist.

                      You select all 4 albums and you get 40 tracks. You select 1 of the 4 albums and you get the 10 tracks that belong to that album.

                      Whether Genre/Artist/Album/Track or Level4/Level3/Level2/Level1 or Level1/Level2/Level3/Level4, they all work like the above.
                      Regards,

                      Rick Tinker (a.k.a. "Tink")

                      Comment


                        #12
                        Originally posted by Rick Tinker View Post
                        You might have to give me a SIMPLE example as I cannot quite be sure it works the way you are saying is good or bad.

                        Each level is a filter, which further reduces the entries at the next level.

                        You select all genres, and you get 1000 artists. You select 2 out of 5 genres, and you get 500 artists that have entries in those 2 genres.

                        You select all 500 artists and you get 300 albums. You select 1 artist and you get 4 albums that match that artist.

                        You select all 4 albums and you get 40 tracks. You select 1 of the 4 albums and you get the 10 tracks that belong to that album.

                        Whether Genre/Artist/Album/Track or Level4/Level3/Level2/Level1 or Level1/Level2/Level3/Level4, they all work like the above.
                        Here are some examples pulled from my yet-to-be-released HS3 DLNA PI. This is a screen capture of how you create actions for events.

                        Note 4 levels is far from enough.

                        This is just an example of the large variety of ways one can navigate depending on the capabilities of the DLNA server. Some servers allow you to customize it even further in more levels; example: after you select lets say albums, it can be configured to have a selection A..Z so the info remains manageable. Actually some DLNA servers do this automatically when the requested amount of objects is large!

                        By the way, the examples shown here is ONE function in my code, you just feed it with a navigation string as to how you got to the level and tell it to go up, into or you're done.

                        I've been thinking about this MediaAPI. I think I can make a fairly simple HS Device with controls, up, down + a few children which hold the navigationstring, an image for the art and a list with selectable items that get linked to a Listbox in HST and be done with it

                        Dirk
                        Attached Files

                        Comment


                          #13
                          Originally posted by dcorsus View Post
                          Here are some examples pulled from my yet-to-be-released HS3 DLNA PI. This is a screen capture of how you create actions for events.

                          Note 4 levels is far from enough.

                          This is just an example of the large variety of ways one can navigate depending on the capabilities of the DLNA server. Some servers allow you to customize it even further in more levels; example: after you select lets say albums, it can be configured to have a selection A..Z so the info remains manageable. Actually some DLNA servers do this automatically when the requested amount of objects is large!

                          By the way, the examples shown here is ONE function in my code, you just feed it with a navigation string as to how you got to the level and tell it to go up, into or you're done.

                          I've been thinking about this MediaAPI. I think I can make a fairly simple HS Device with controls, up, down + a few children which hold the navigationstring, an image for the art and a list with selectable items that get linked to a Listbox in HST and be done with it

                          Dirk

                          .... did I mention ..... no own Database for the PI that requires synching etc


                          I can post some examples of navigating through Windows Media Player if you like ....

                          Comment


                            #14
                            Dirk summarizes it well illustrated by the different possible navigation depth in his screenshots:
                            • "no own Database for the PI that requires synching" - absolutely
                            • An API / UI workflow to navigate up/down the hierarchy tree. Given a node in the tree (by its key), the API returns children (which are media lib_entry at the leaf and grouping nodes/folders at non leaf levels)

                            If the levels are filters as you suggest, the API implementation is a search / query approach not a tree walk up/down one at a time. In your example "You select 2 out of 5 genres" or "select tracks for artist X for all genres", and for media libraries (for that service) organized as a tree that needs to be walked, you need to walk the tree genre by genre, artists by artist, etc do a pattern match and collect entries to be returned. You query it as "select * from media_library where (genre = a or genre = b) and artists = "z". The PI implementation would either need to build a queryable database model for these services to perform the search/query (difficult to implement, maintain and to keep in sync) or walk all nodes in the tree (over the internet for some) for medias that are organized in a tree hierarchy performing pattern matching/searches to collect what needs to be returned; which is unpractical for some media libraries with inadequate response times.


                            I agree with Dirk that an API to walk a tree node by node (using keys/values) listing children in a list box without assumptions of depth would be much simpler and of wider usage (beyond media usage).

                            Comment


                              #15
                              Originally posted by dcorsus View Post
                              Note 4 levels is far from enough.
                              TOTALLY disagree, and you guys are missing the point completely.

                              First of all, there is nothing stopping you from providing additional selection criteria in your plug-in. The goal in having an API is to have some COMMON GROUND for all things to use. If you want to have your own player UI that has all the bells and whistles for selecting media, and you even want HSTouch clients to have to load a web page from your plug-in, then go right ahead - that is perfectly fine. But if you want the ability for somebody else's UI to make selections of media in your plug-in, then you need that basic four levels of selection implemented. You can go above and beyond that if you wish, but the STANDARD does NOT need more than four levels.

                              In your example, Root level is totally unnecessary - what else would you select besides what you are calling the root?

                              The four levels are for selection of media based upon totally unknown information - e.g. text that makes up the genre, artist, album, and track. When you get into date, rating, bpm, etc. you are getting into filters for the selected media, AND those filters are not based upon random text - they are fixed items, typically numerical data. It is a very fine distinction, but I think what you guys are missing is the difference between a MINIMAL IMPLEMENTATION REQUIRED FOR AN API versus everything that you guys want and think it should have.

                              And it does NOT matter HOW you implement things in YOUR plug-ins. The API gives you the ability to display a list of items at a level, collect selection(s) from the user which are passed to your plug-in, and then you update the displayed information. I don't care if you select directly from your library or have your own database!
                              Regards,

                              Rick Tinker (a.k.a. "Tink")

                              Comment

                              Working...
                              X