Corrupt ini File Options

[Mark S.]

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.

[dcorsus]

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

[Mark S.]

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.

[dcorsus]

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

[Mark S.]

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 S.]

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?

[dcorsus]

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.

[Mark S.]

It happened again. This time, 5 of my 8 player no longer work via HS, but still work via the Sonos app. They all seemed to stop working on the same day in late March, based on their last device change dates.. Interestingly, the three most used players still work (which is why I didn't notice the loss of the other 5 until recently). I do not see the "listening" log entry per your last post. I attached the Sonos-related log entries during startup (reverse order).

Again, I'm only guessing that some file or association is getting corrupted somehow. Replacing the hsd file or replacing the sonos.ini file have not fixed in in the past. Replacing the entire HS3 directory with a backup has fixed it in the past, but I have not yet tried that this time.

[dcorsus]

It happened again. This time, 5 of my 8 player no longer work via HS, but still work via the Sonos app. They all seemed to stop working on the same day in late March, based on their last device change dates.. Interestingly, the three most used players still work (which is why I didn't notice the loss of the other 5 until recently). I do not see the "listening" log entry per your last post. I attached the Sonos-related log entries during startup (reverse order).

Again, I'm only guessing that some file or association is getting corrupted somehow. Replacing the hsd file or replacing the sonos.ini file have not fixed in in the past. Replacing the entire HS3 directory with a backup has fixed it in the past, but I have not yet tried that this time.

Don't go deleting or replacing anything, if you don't mind. While I'll have a look at your log, can you post a screenshot of the player table AND click on the button at the bottom which reads "view Sonos Devices" and post that screenshot. Please confirm you are on the latest PI version which is .52 in the beta section.

[dcorsus]

Could you take the start-up log again but make sure you set debug log level to errors and events . UPNP debug level to errors only.
I would use the log to disk option (believe I posted how to do that) and not copy/paste into a word doc.
You use a interesting IP address, which is not in the private address range, on purpose or mistake?

[Mark S.]

OK, here is my stuff. Obviously, this required a reboot and that seems to have changed things even more. I am not on .52 because I assumed it was beta and I typically avoid betas. But I will update if it might help this issue. I've been using that IP address range for decades, don't remember why it started, but my entire network is set up that way, so it remains.

[dcorsus]

Thanks for the info. I'm not saying that using the 122.xx.xx.xx address range causes your issue, the problem is that you should not use a public address range for your internal network. The problem it creates is that you black-hole parts of the public network. Think of this artificial example: just assume for a second that Google used 122.xx.xx.xx you wouldn't be able to access that service because your network settings is configured to go hunt on your LAN as opposed to go to your WAN and reaching the proper global service. Any www.xxx.xxx service that translates into a 122.144.166.xx IP address would not be accessible.

Anyhow, the log shows that zero players are discovered using multicast at start-up, so that is an issue!. They do dribble in but I suspect the reason you can't seem to properly keep them "connected" is that there is something off with either firewall setting on the PC or perhaps something else. The first issue that comes to mind, is switches that you use in your network and its multicast setting. So how does your network look like? Can you describe? Use VMs?

You are actually on a version that is about a year old (http://plugins.homeseer.com/releasenotes?productid=271), not sure there is anything that I added since version .28 that would explain your issue but I did make some robustness improvements since .28. The latest is .52 (in beta section of updater) and I understand you stay away from betas, but the "official" version is .51 and for me there typically is no difference between beta and official and I tend to update the official if there is a real issue solved as opposed to perhaps some cosmetics of minor new things. Given you have S12 and S16 players, suggest you upgrade to .52 and give some insight how your network between HS PC and players is built.

[dcorsus]

Actually on second thought, there is something in v49 that I fixed that may "help" to keep you players on-line, but you may still have an underlying network setting issue.

• Fixed rediscovery, broke it in v27

[paul]

Indeed, I'd recommend going to .52 before trying anything else - I was having issues with losing speakers and it was proving to be a real issue to track down. The discovery fixes dcorsus put in fixed it for me...

[Mark S.]

OK, updated to .52, but not seeing any change. Still a few players work, but the rest NG. Updated files attached.
Regarding the network, it is just a router and a few switches. No VM. My Hometroller and my Sonos devices are all connected to Cisco SF 100-24 dumb switches which are connected to my ASUS router. Networking is a bit over my head as you can tell from my 122.xxx, so no clue on what multicast is.