Prototype Minster Music Software

[TerryJC]

So which should I do merge, rebase or fast-forward?

Ignore this, I've just realised that the version in Tools for the Minster program is older than the version in Tools for the River System code. I must have done the pull in rivercontrolsystem/ and then forgot to cp it to the minster directory.

Sorry about that.

I'd still like to understand the merge query.

[hamishmb]

I wonder whether your local repository is old enough to be pulling from the old GitHub repos instead of GitLab, that might explain it. I'd just delete the whole local repository and clone it again unless you have a reason not to.

What is the output of:

Code: Select all

git log

That way I can verify if your repository is up to date. The last commit was in December 2020 I think.

Merge query:

I personally use the default of:

Code: Select all

git config --global pull.rebase false

The logging.getLogger() lines I referenced are at the top of sockettools.py and need to be changed.

[TerryJC]

I wonder whether your local repository is old enough to be pulling from the old GitHub repos instead of GitLab, that might explain it. I'd just delete the whole local repository and clone it again unless you have a reason not to.

No. I'm definitely pulling from the GitLab Repository:

Code: Select all

git remote -v
origin  [email protected]:wmtprojectsteam/rivercontrolsystem.git (fetch)
origin  [email protected]:wmtprojectsteam/rivercontrolsystem.git (push)

As mentioned the error was all mine when I pulled the latest verion in December and then forgot to copy it across.

What is the output of:

Code: Select all

git log

That way I can verify if your repository is up to date. The last commit was in December 2020 I think.

See attached.

Merge query:

I personally use the default of:

Code: Select all

git config --global pull.rebase false

OK. Thanks. I'd not seen that message before.

The logging.getLogger() lines I referenced are at the top of sockettools.py and need to be changed.

Ah! You never mentioned that these lines are not in my code!

You never answered my query about the discrepancy of the logger names between the Music and Bells code. When you say Names, do you mean the names in quotes. I made those different to match the Pi that the log was coming from.

[TerryJC]

You never answered my query about the discrepancy of the logger names between the Music and Bells code. When you say Names, do you mean the names in quotes. I made those different to match the Pi that the log was coming from.

Hamish,

I assumed that what you meant is that the Names were the names in quotes and have changed the names to both read 'Minster Software'. That seems to work OK, but I'm not sure what it's done.

Anyway, having done that, I installed the latest version of sockettools.py and re-instated the code as you suggested in viewtopic.php?p=4640#p4640 and no longer get the args error.

However, when the connection has been successfully made, I still get the "Connected to peer (Music Pi Socket)" from both Pis. Have I missed something else?

I've pushed the latest code to GitLab.

One other thing. I notice that after the code issues 'Waiting for peer to connect...' to the shell, it eventually writes the Connected message, as above. However, the log only contains the Waiting message and not the Connected one. I can see in the code why this is; the message is only written to the debug log, but is there any reason for this?

[hamishmb]

The repo looks fine, so that's good.

I must have missed that somehow. Yes, I mean the names in quotes eg: "Minster Music Software" and "Minster Bells Software". Either I would standardise these, or save the name in config.py (as say CONFIG.loggername) and have sockettools.py read it when it loads. However, that makes the order that modules are imported potentially problematic so I would just use the same logger name for both programs - they are part of the same system, after all.
I see you've already done that while I was typing this out

Response to the sockettools logging query:

You should get a line that corresponds to:

Code: Select all

logger.info("Sockets._create_and_connect(): ("+self.name+"): Done!")

In your log. If you get nothing from sockettools.py, it is likely because the logger name isn't set correctly there when it's getting settings for its own logger. Did you also set the correct logger name in the logging.getLogger() calls at the top of sockettools.py?

Response to the socket name query:

Looks like in your code you're supplying the same string ("Music Pi Socket") in both programs for the same. If you set the third argument to something else then that will change the name of the socket in the logging messages.

[TerryJC]

Response to the sockettools logging query:

You should get a line that corresponds to:

Code: Select all

logger.info("Sockets._create_and_connect(): ("+self.name+"): Done!")

In your log. If you get nothing from sockettools.py, it is likely because the logger name isn't set correctly there when it's getting settings for its own logger. Did you also set the correct logger name in the logging.getLogger() calls at the top of sockettools.py?

I did change it in sockettools as well as the two programs. You can see what I did in the latest commits on GitLab.

Response to the socket name query:

Looks like in your code you're supplying the same string ("Music Pi Socket") in both programs for the same. If you set the third argument to something else then that will change the name of the socket in the logging messages.

This is where I'm getting lost. In both programs, I use the same code:

Code: Select all

site_settings = config.SITE_SETTINGS["BELLS"]

because if I use:

Code: Select all

site_settings = config.SITE_SETTINGS["MUSIC"]

in the server program it fails because the server has no SocketName. This matches what you suggested originally and the question goes back to my uncertainty regarding the correct entries for config.py. Could you have a look at what is in there on GitLab?.

Sorry to be so dense here.

[hamishmb]

Okay. had another look. Had a look just before but I think that was just before you uploaded the commits.

To fix the sockettools.py logging, you'll need to import sockettools after running init_logging() for both programs. The problem at the moment is its trying to configure its own logger to match the main one before the main one has been configured.

Yeah, the site settings there are fine, just specify, for example:

Code: Select all

socket = socket_tools.Sockets("Socket", "MUSIC", "Bells Pi Socket")

Instead of:

Code: Select all

socket = socket_tools.Sockets("Socket", "BELLS", site_settings["SocketName"])

In minstermusic.py. I changed the site ID in the call here too because that is also set incorrectly at the moment.

Hope this helps.

[TerryJC]

Hamish,

That's done it

I'm now getting the logging that I expected and the two sockets are identified correctly.

Thanks again for your help.

[hamishmb]

Ah good, glad it's working now.

[TerryJC]

I've just pushed a new version of config.py to GitLab, together with some corresponding updates to the two player programs.

The reason for these changes is to cater for the exchange of data between the Webserver and the Music Player program as well as the exchange of data between the Music Player program and the Bells Player program. I have tested that the latter functionality still works, but now have to add the sockets code to the Webserver and the new sockets code to the Music Player program. This will be a fairly major exercise because in order to test this functionality I will have to fully deploy the Webserver onto the Pi (its been tested on my desktop so far). My biggest concern is the possibility of problems because the sockets server in the Music program and the sockets server in the Webserver both have the same IP Address, although they do have different IDs.

Hamish,

Could you have a look at the updated config.py to see if I have understood what's needed? It may save me some confusion later if I've got this bit wrong.