Announcement

Collapse
No announcement yet.

Corrupt ini File Options

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

  • Corrupt ini File Options

    At least once per year, the plugin stops working, presumably due to a corrupted ini file. Typically, it seems to happen after a power failure. The standard prescription is to delete the ini file and restart. But this recreates all the devices, assigning all new HS Reference numbers. And my Ref numbers are well into the thousands because this has happened so many times. Anyway, the result is that it literally takes days to fix scripts and HSTouch screens for 8 players and about 10 touchscreens. This process has gotten real old.

    Is there some way to repair the ini file? What should I look for? I have attached the one that no longer seems to work.
    Attached Files
    Mark

    Hometroller S6 w/ HS3Pro, Way2Call
    BLAB8SS, BL Backup, Easy Trigger, HSTouch, Open Sprinkler, SONOS, Ultra1Wire3, UltraM1G, WeatherXML, Z-Wave

  • #2
    Originally posted by Mark S. View Post
    At least once per year, the plugin stops working, presumably due to a corrupted ini file. Typically, it seems to happen after a power failure. The standard prescription is to delete the ini file and restart. But this recreates all the devices, assigning all new HS Reference numbers. And my Ref numbers are well into the thousands because this has happened so many times. Anyway, the result is that it literally takes days to fix scripts and HSTouch screens for 8 players and about 10 touchscreens. This process has gotten real old.

    Is there some way to repair the ini file? What should I look for? I have attached the one that no longer seems to work.
    I don't see anything wrong with the .ini file. Most problems that appear aren't necessary that the .ini file is corrupted, the root is that the HS DB isn't in sync with the .ini file. I actually don't see issues with this .ini file so let's go back to what exactly is it you see? If I parse your statement:

    1. "The PI stops working": Can you describe what is not working?
    2. "Usually after a power failure": do you see other issues with HS? Is this a Linux or windows environment? Do you see errors in the log?

    So here is some background: the PI hardly ever writes to the .ini file, so the likelihood it gets corrupted due to excessive writing and coincidental restart is small. Secondly, the PI does not write directly to the .ini file, it actually calls HS to access the file. However, HS introduced a caching mechanism a long time ago and initially had some issues with it. So a restart of HS could indeed causes issues with .ini file. So are you on a more recent HS version? Having that said, because the .ini file is not written in a lot, they don't get corrupt easily. All the postings you find here is typically because the HS DB got corrupted OR the user begins manual interventions and actually causes all the issues.

    So is the system currently not working and the ini file you posted belong to a non functioning PI? If so here's what I want you to do:
    1. turn the PIs debug flag on and restart HS. Capture log and post. Look for errors.
    2. look at the PIs devices table (on the config page), do you see duplicated devices? If you don't; the problem is somewhere else.

    If HS restarts occasionally, perhaps there is a more fundamental issue, such as memory issue or HW issue and you might want to focus on that. The use of the ini file, now 8 years or so after I created the PI, could have different ways to be implemented that didn't exist when I started with HS2. Having that said, the corruptions are almost non-existing (had some over the years when HS was making changes to their ini file caching) but DB out of sync have happened quite a bit and again, most of those were due to either the HS DB was foobar or the user began deleting things to the point their setup wasn't functioning.

    So before someone asks why I don't store the info into the HS devices itself, the PI has a lot more info that is not associated with one device, things like linkgroups etc and therefore there is simply no way around the fact that the PI needs some config storage.

    I do see that you have plenty of touchscreens, does that mean you use the MediaAPI functions (navigate content)? Reason I ask, is that I don't recommend you to use it because the implementation is SOOOOOO inefficient that it could cause a lot of load on the PI. Also, check your DB creation settings. If they are set to "immediate" I would recommend you set to a daily/nightly recreating and always make sure their is enough memory available on your system. If you have a large music selection that your Sonos system has discovered, the music DB can be quite large and it could easily demand a few 100Mbyte WHILE it is being created. Once the DB is created, all the memory is released but it can spike quite a bit.

    Hope this helps, sorry for the problems, happy to look at more logs if you have them.

    Dirk

    Comment


    • #3
      Thank, Dirk. That explanation definitely helps me understand a bit more.

      Anyway, by not working, I mean unresponsive - cannot play a sound, speak, change volume, play music - nothing via HS. But of course my speakers still work with the Sonos app. Regarding other power failure effects, my Elk alarm system lost its IP address, but nothing else that seems HS-related.

      I have attached the Sonos-related stuff in the startup log with debug on, and I also attempted to play a sound/announcement around 8:54:52. I also included a screen shot of the devices on the SonosConfig page.

      I am not using the MediaAPI, although I wish I could. That was great when it worked. No immediate DB checkmark.

      I also tried shutting down, replacing the HomeseerData.hsd file and the Sonos.ini file from a backup a few weeks ago (when everything worked fine) and restarted, but still no good.

      Thanks for your help.
      Attached Files
      Mark

      Hometroller S6 w/ HS3Pro, Way2Call
      BLAB8SS, BL Backup, Easy Trigger, HSTouch, Open Sprinkler, SONOS, Ultra1Wire3, UltraM1G, WeatherXML, Z-Wave

      Comment


      • #4
        Originally posted by Mark S. View Post
        Thank, Dirk. That explanation definitely helps me understand a bit more.

        Anyway, by not working, I mean unresponsive - cannot play a sound, speak, change volume, play music - nothing via HS. But of course my speakers still work with the Sonos app. Regarding other power failure effects, my Elk alarm system lost its IP address, but nothing else that seems HS-related.

        I have attached the Sonos-related stuff in the startup log with debug on, and I also attempted to play a sound/announcement around 8:54:52. I also included a screen shot of the devices on the SonosConfig page.

        I am not using the MediaAPI, although I wish I could. That was great when it worked. No immediate DB checkmark.

        I also tried shutting down, replacing the HomeseerData.hsd file and the Sonos.ini file from a backup a few weeks ago (when everything worked fine) and restarted, but still no good.

        Thanks for your help.
        At start-up, the PI seems unable to detect any of the players, this might be a firewall or network issue. Is this on Windows? If so, make sure the PI itself has all firewall allowance for port access (incoming and outgoing). If you have managed switches, makes sure they allow proper multicasting (best option is typically to turn snooping OFF). If this runs in a VM, it needs to be set in bridged mode not NAT mode! The IP address space in use 122.144.166.xx as far as I can remember, that is NOT a private address space is it? If not, you are now blacklisting part of the internet as these addresses should be having a path out towards your ISP. I don't think this is your problem but it raises red flags for me.
        I need to check my code why the players seems to indicate they are on-line whereas the log shows zero players discovered, at least at start-up.
        Dirk

        Comment


        • #5
          I checked my firewall and network settings - nothing amiss. Anyway, I finally fixed it by replacing the entire HS3 directory with a backup. So apparently some file in there was corrupted, but apparently it wasn't the .hsd or the sonos.ini because I had already tried those. I may never know which one, but thank goodness for BLBackup.
          Mark

          Hometroller S6 w/ HS3Pro, Way2Call
          BLAB8SS, BL Backup, Easy Trigger, HSTouch, Open Sprinkler, SONOS, Ultra1Wire3, UltraM1G, WeatherXML, Z-Wave

          Comment


          • #6
            This has happened a few more times since my last post. The plugin stops working as above - seems to happen after a crash of HS. I cannot determine what causes the HS crash, but apparently something gets corrupted in the process that breaks something between HS and the Sonos PI. It seems to be an association because none of the Sonos devices update anymore - all other plugins still work fine. Dirk - I believe you are right in that the Sonos files are fine - I have tried replacing them with good backups, but the PI still does not work. It seems to be some corruption with HS, but I have no idea what file. I've tried just replacing the hsd file with a good backup, but no go. If I replace the entire HS directory with last week's backup, I get back up and running, but that is getting tedious. Any ideas what to look for?
            Mark

            Hometroller S6 w/ HS3Pro, Way2Call
            BLAB8SS, BL Backup, Easy Trigger, HSTouch, Open Sprinkler, SONOS, Ultra1Wire3, UltraM1G, WeatherXML, Z-Wave

            Comment


            • #7
              What version of the Sonos PI are you on? Make sure you are on the last because there were some issues that snuck in, in the last 6 months.

              Secondly, if HS crashes, nowadays with PI running as separate .exe you need to be looking for things like looping scripts or resource issues. Other source is an interaction between PIs. Say, the Sonos PI generates a log entry, and you have say a PI that triggers something based on the log entry and commands the Sonos to do something, which cases a log entry while one was still pending etc. A year or perhaps 2 ago, Rich was chasing one of these loops where an HSEvent was intercepted by a PI but the PI caused more Events before the event was treated etc.

              The Sonos PI is really very static wrt to data it stores, it is all very dynamic. Only time when things are written is when a device is discovered (I'm referring to the sonos.ini file), there are of course HS devices that get updated, some of them each second (track position) but the only reason HS would keel over is because something else is eating resources and it either runs out of memory or you have some real HW issue causes either memory corruption or flash corruption.

              There is one time when the Sonos PI could potentially use a lot of resource, that's when it is building it's music DB. During that time, I see a lot of memory being used until the DB is closed. If you have many tracks on your Sonos devices, I've seen it go over 100Mbyte but it all gets released. If you run short on resources, this could be a trigger for a crash as the PC runs out of resources. I recommend people to do nightly builds and for sure not set it to "immediate" anymore. 10 years ago when I started the PI, adding tracks to you share was something that happened very sporadic, nowadays, allowing you to vote on tracks etc, the Sonos DB changes a lot more, so doing "immediate" updates could be part of the problem. I'm removing this option in HS4.

              Now, I recently discovered something while testing my HS4 PI. If HS comes up, say after your restart, and the network is unavailable, there won't be any IP address assigned and the Sonos PI will come up not knowing which interface & subnet to probe to discover players. Unfortunately, I have no way to detect an issue like that (because HS will give me some default/wrong IP address) nor is there a way to notify the PI that HS changed or received a different IP address.

              If you hunt for this line in your start-up log, you could see if the PI is working on the wrong IP subnet
              MySSDP.StartEventListener started listening

              That's all I can think off.

              Comment

              Working...
              X