Announcement

Collapse
No announcement yet.

Stale Player Issue and Virtual Device Portablility

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

    Stale Player Issue and Virtual Device Portablility

    Hi,

    I have been going through replacing my wall mounted tablets which also double as squeezebox players.

    From my attachment you can see that I have quite a few duplicates. I would effectively like to remove the duplicates without having to recreate the HS3 devices. I have many events (hundreds) that trigger based on these devices as well as many statically assigned hstouch screens that reference these devices.

    I have tried going in and removing the stale players in the config.ini file however since there would be missing players it reassigns the numbers which screws up the virtual devices making you recreate them.

    Since all of my players are software based players it would be most helpful we could assign the instance some how to reference a certain player, other than it getting recognized automatically and assigned a new player number.

    For instance on my squeezelite player that I had running on OFFICE... I recently changed computers to a laptop and removed the old machine. I use a batch file to start the process and it allows me to enter a virtual MAC address of the player (which is used on the cloud service I think)

    Code:
    "C:\Program Files (x86)\SqueezeLite\squeezelite-win.exe" -o 4 -n OFFICE -s 192.168.1.108 -m 00000000000000B2
    Perhaps at least with my windows software squeezebox players you could match based on that so that I don't have to painstakenly go through every event and hstouch screen should I have to replace my computer again as it looks like it is matching based on the physical MAC address.

    I also use android software players and I am not sure that there is a way to assign the MAC address however there should be a to keep things a bit more portable.

    Now I have no idea whats going on under the hood here so perhaps you could weigh in and let me know if you think any of this is feasible.

    Essentially what I am after is a way to remove stale players without screwing up the actual virtual devices of the players (i.e. if I manually remove player 9 from the INI file Player 10 gets messed up).

    Secondly, better portability for software based players for instances when the hardware changes
    Attached Files

    #2
    Originally posted by skarragallagher View Post
    Hi,

    I have been going through replacing my wall mounted tablets which also double as squeezebox players.

    From my attachment you can see that I have quite a few duplicates. I would effectively like to remove the duplicates without having to recreate the HS3 devices. I have many events (hundreds) that trigger based on these devices as well as many statically assigned hstouch screens that reference these devices.

    I have tried going in and removing the stale players in the config.ini file however since there would be missing players it reassigns the numbers which screws up the virtual devices making you recreate them.

    Since all of my players are software based players it would be most helpful we could assign the instance some how to reference a certain player, other than it getting recognized automatically and assigned a new player number.

    For instance on my squeezelite player that I had running on OFFICE... I recently changed computers to a laptop and removed the old machine. I use a batch file to start the process and it allows me to enter a virtual MAC address of the player (which is used on the cloud service I think)

    Code:
    "C:\Program Files (x86)\SqueezeLite\squeezelite-win.exe" -o 4 -n OFFICE -s 192.168.1.108 -m 00000000000000B2
    Perhaps at least with my windows software squeezebox players you could match based on that so that I don't have to painstakenly go through every event and hstouch screen should I have to replace my computer again as it looks like it is matching based on the physical MAC address.

    I also use android software players and I am not sure that there is a way to assign the MAC address however there should be a to keep things a bit more portable.

    Now I have no idea whats going on under the hood here so perhaps you could weigh in and let me know if you think any of this is feasible.

    Essentially what I am after is a way to remove stale players without screwing up the actual virtual devices of the players (i.e. if I manually remove player 9 from the INI file Player 10 gets messed up).

    Secondly, better portability for software based players for instances when the hardware changes


    I am traveling for another week without access to a computer or software to check options in details. It uses the player LMS id (MAC address typically) to identify players. If I recall there is an option in the ini file to disable a player, but don't recall the config parameter.

    Comment


      #3
      No problem, ping me when you get back

      Comment


        #4
        Any chance you can help me get rid of or disable stale players without having to recreate all devices? I am still in the save situation...

        Comment


          #5
          KNown players by the plugin are trackied in the plugin ini file (hspi_squeezebox.ini) as below showing the relevant entries:

          Code:
          [player 2]
          Name=Squeezebox Living Room
          ID=00:00:00:00:00:00
          HSDevices=False
          The ID is the critical one and is the unique ID per player as identified by LMS. Typically this is the MAC address. AS you metnion for soft players you can specify it with the -m option.

          When the plugin starts, it builds the list of players based on the list of know players in the INI file iterating over all [player x] sections looking for non blank Name and non blank ID entries. Then when the plugin is connected to LMS it matches current player IDs from LMS with this know player list, extending it as needed (soft players might not always be connected, though in HS3 we still want their definition and devices).

          The player ID is also used to build the plugin instance (The instance in your screenshot below) that will than own the player devices (i.e. the HS3 dv.InterfaceInstance of the device matches the plugin instance).

          Given above, here are some options:
          - for soft players, can you always specify the same MAC address (-m option in your command line) to ensure it does not change?
          - For others, you can edit the ini file to replace the ID for player with the new one if it changed, but to ensure all devices associated with a player have the instance of the device (dv.InterfaceInstance) is updated to the new instance given the new ID. The plugin has no built-in support for this (maybe in the future). This can be done with a script, though do not have one handy to do this.

          Hope this helps. I will keep this on my list to see if I can add a 'migration' facility within the plugin in a future release.

          Comment


            #6
            Originally posted by pcp View Post
            KNown players by the plugin are trackied in the plugin ini file (hspi_squeezebox.ini) as below showing the relevant entries:

            Code:
            [player 2]
            Name=Squeezebox Living Room
            ID=00:00:00:00:00:00
            HSDevices=False
            The ID is the critical one and is the unique ID per player as identified by LMS. Typically this is the MAC address. AS you metnion for soft players you can specify it with the -m option.

            When the plugin starts, it builds the list of players based on the list of know players in the INI file iterating over all [player x] sections looking for non blank Name and non blank ID entries. Then when the plugin is connected to LMS it matches current player IDs from LMS with this know player list, extending it as needed (soft players might not always be connected, though in HS3 we still want their definition and devices).

            The player ID is also used to build the plugin instance (The instance in your screenshot below) that will than own the player devices (i.e. the HS3 dv.InterfaceInstance of the device matches the plugin instance).

            Given above, here are some options:
            - for soft players, can you always specify the same MAC address (-m option in your command line) to ensure it does not change?
            - For others, you can edit the ini file to replace the ID for player with the new one if it changed, but to ensure all devices associated with a player have the instance of the device (dv.InterfaceInstance) is updated to the new instance given the new ID. The plugin has no built-in support for this (maybe in the future). This can be done with a script, though do not have one handy to do this.

            Hope this helps. I will keep this on my list to see if I can add a 'migration' facility within the plugin in a future release.
            Thanks for the reply and for the detailed information. I will play with it a bit. Ultimately I think the shortest path to resolution is to rebuild the devices on my end and modify the events

            It is really necessary though to have an easy way to remove these stale devices, perhaps you can look into this as well. It seems that when I modify the INI file directly it throws off the player number and ends up adding new players

            See picture
            Attached Files

            Comment


              #7
              It is on my list to look into ways to support cleaning / removing players for a future version, but not sure when that will happen.

              Comment

              Working...
              X