Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update priority channel approach #11

Open
lordmorgul opened this issue Dec 16, 2023 · 12 comments
Open

update priority channel approach #11

lordmorgul opened this issue Dec 16, 2023 · 12 comments

Comments

@lordmorgul
Copy link
Collaborator

lordmorgul commented Dec 16, 2023

Capture updated priority channel code from lordmorgul fork master branch

I will work transferring the updated channel priority approach from my fork master branch. It has been tested for a couple weeks and seems ready to bring into a new branch here and test. It lets fewer demodulators run simultaneously to have several priority channels, as long as the channels are not frequently all in use.

@lordmorgul lordmorgul changed the title Capture updated priority channel code from lordmorgul fork master branch update priority channel approach Dec 16, 2023
@lordmorgul
Copy link
Collaborator Author

@john- seems I failed to accept the collab invite, thought I did that but it was still showing and too old. Please redo that.

@lordmorgul
Copy link
Collaborator Author

lordmorgul/ham2mon - priority demod assignment commit here
to be manually pulled lordmorgul@a059c00

@john-
Copy link
Owner

john- commented Feb 25, 2024

Per comments in the pull request for this feature I took a look at an alternate approach for this enhancement. I think I got the idea behind it and it is documented as a use case in the README.

https://github.com/john-/ham2mon/tree/priority_handling_alternate_squashed

I tested the following scenarios:

  • master branch, feature branch with no priority file, and feature branch with priority file (2 entries)
  • one demodulator vs three demodulators
  • with and without audio classification

I did not test with sound through speakers only with recording.

Of course, more testing is required and confirmation that it at least minimally addresses the requirement.

@john-
Copy link
Owner

john- commented Mar 7, 2024

This is now part of the master branch. Closing ticket.

@john- john- closed this as completed Mar 7, 2024
@lordmorgul
Copy link
Collaborator Author

Sounds good, I will get this and test live listening to a repeater thru speakers.

@john-
Copy link
Owner

john- commented Mar 8, 2024

Sounds good.

The master branch includes a bunch of other changes as well. If there are problems it should be possible to go to previous commits to better isolate things.

@lordmorgul
Copy link
Collaborator Author

Testing Master today there is an issue with "tmp" directory not being included in git so new deployment does mot have it. Soon as a signal is classified as voice program crashes when tmp is not found. Creating tmp locally fixed it.

Channel priority seems to be working for Case 3 priority listening. Will keep doing more testing.

@john-
Copy link
Owner

john- commented Mar 10, 2024

Thanks for the feedback.

I will look at the tmp dir issue. What is odd is that the code removes the directory on exit so there is code to create it if it does not exist. Clearly there is something weird going on.

@john-
Copy link
Owner

john- commented Mar 10, 2024

This code hasn't changed in a while but maybe this line is failing for some reason:

os.makedirs('wav/tmp')

@john- john- reopened this Mar 11, 2024
@john-
Copy link
Owner

john- commented Mar 11, 2024

I did a clean git pull and master branch. I ran ham2mon with audio classification and it did not error out due to missing wav/tmp directory. I reopened this issue. Can you reproduce it? If so maybe we need some debugging code to figure it out.

@lordmorgul
Copy link
Collaborator Author

For my crashes it was creating the directory in 'apps/tmp' instead of 'apps/wav/tmp' that made it stop crashing. The code attempts to always work in 'apps/wav/tmp' first then move to 'apps/wav' so I'm not sure why that error came up trying to write to the higher tmp.

@john-
Copy link
Owner

john- commented Mar 16, 2024

Yeah that is odd. Maybe just watch it for now.

At some point we should move the file writing to the newer pathlib. That should clean up the code in this area. I also want to get rid of the .replace calls which bother me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants