Personally, I would find it very helpful to have a volume control slider (preferably next to the play button) to control the volume of playback.

Just a heads up that it seems the email address in the password reset function is case sensitive. If you use a different case for the email address than you signed up with, it will respond with No account register for [email protected].

This is a continuation of this issue: robotastic/trunk-recorder#331 from Trunk Recorder to cover items that could be handled server side.

I think I could add something to handle this... the basic plan would be to add a do-not-play-until field to all the call records and then make that part of the Call Fetching search. I would have to check and see what that would do for performance.

OpenMHZ is completely crashed and down as of about 10:30 PM EST.

Not working over 24 hours now

The default username and password do not work on the account.openmhz.test site.

Hi, are there docs on the API anywhere?

Thanks!

As of last night, systems are not streaming on mobile devices, only on PC

Modern trunk-recorder versions include the patched_talkgroups attribute within a call.

It would bre awesome to extend OpenMHz to support this (would also need to update the openmhz_uploader plugin in trunk-recorder), and include the call in both talkgroups.

If the current model can't easily be extended to allow a single call to exist in both TGs, could also create a copy of it in each TG.. but that would result in duplicate calls if the end user has both TGs selected.

The Download event function has a small ease of access problem.

Because of the way files are automatically named, when a number of calls from 2 or more talkgroups are downloaded from the same event they will appear in the folder out of order.

This is due to the names assigned to the files. when downloaded the files will appear like such:

ex. mocomdps-4005-1676726457

'mocomdps' being the radio system '4005' being the assigned talkgroup number and I don't know what the third number is.
if you download an event with calls from mult. talkgroups (say TG 4000, 4005, and 4010) the 4000 talkgroups will appear in the file first due to alphabetization order then the 4005, then 4010.

So a proper sequence of calls say transmissions on 4000, 4010, 4005, 4010, 4010, and 4000 again will download as
4000, 4005, 4010, 4010, 4005, even thought this is now out of order

I'm currently attempting to connect to the OpenMHz web socket and receive live call information using the following code without success. I don't see what the webapp is doing differently, either from looking at CallPlayer.js, or the Firefox Network console.

The Gist is here: https://gist.github.com/mepholic/e188c4bf1b2550f936598747a271c778

I noticed that performance was kind of crummy on my test OpenMHz box for the calls list (older/newer), so took a look at Mongo.. and we're not creating an index for that!

I need to dig into how to do this properly with Mongoose, but in the meantime..
db.calls.createIndex( { "shortName": 1, "time": 1, "talkgroupNum": 1 } )

This takes requests from a few hundred milliseconds down to 10ms or so on my crummy test box.

All the FDNY feeds are down since yesterday, except for CW-2...

I've started to listen to OpenMHz on my cell phone (iPhone) and noted that due the lack of a constant stream (which is the nature of calls), my phone will not play new calls if my phone is not on the webpage. While this in and of itself is a feature that would be awesome, I expect it is a hard solution.

In the meantime, I propose when autoplay is enabled on a feed, that OpenMHz keeps the screen awake. This would allow new calls to be played because they webpage is still in the foreground of the cell phone.
I believe this can be done so via NoSleep.js outlined here.

Just wanting to know if this will work on the Raspberry Pi 3B+?

I accidentally pressed the star button on a transmission (nice addition by the way) and now there's no way to undo it.

It would be great if OpenMHz would auto-scroll to keep new calls at the top, similar to Broadcastify Calls.

Occasionally the call list will have a duplicate message come in during or after a message has already been received. This will sandwich individual records, but then the autoplay will pass over the second duplicate and skip playing of the individual records.

In the above case you can see that there are a few unique messages in between these duplicates, but those won't be played as the top duplicate will be interpreted as the call that is "currently playing". It looks like this happens when calls come in with a later timestamp before messages in the regular chronological order come in. The second record comes in on the chronology where it normally should, but since it already came in it becomes a duplicate.

Also, thanks for all the work you've put into this :) It's been amazing to use!!

Looks like a typo at line 77 of admin/controllers/talkgroups.js

No calls play any audio, auto-play immediately skips to next call. Tested on Hennepin County Armer east and west. Issue is noted on Google Chrome using a pixel 4xl, pixel 7, PC. Tested on Edge on PC as well.

During the past couple of days I'm encountering issues across all FDNY talkgroups, you hear intermittent 20 sec beeps (yeah, like that beep when they transmitting a job...)

Now I'm not getting any transmissions on the Brooklyn talkgroup except for that annoying 20 sec beep, and I know it's not a borough problem because it works all fine on broadcastify, so it's defiantly on the MHZ end

Here's a direct link to the talkgroup: https://openmhz.com/system/fdnyfire?filter-type=talkgroup&filter-code=4

If you assign your system location to be a county, it shows up as undefined, STATE in the Systems list. Assigning a city or only a state seems to work correctly.

SCENARIO:
There's an incident and you go find the first call about it and use the Link feature to share it with others/for later.

Expected results:
The link (https://openmhz.com/system/system?filter-type=talkgroup&filter-code=###&time=#####) opens with the call specified selected and following calls loaded

Actual result:
The specified call is the latest one loaded and is not selected. Looking at the browser console, the calls/newer? URL is never fetched on page load. Sometimes, scrolling down and then up does get newer calls to load.

Not sure this is the right place for it, but it would be nice to have links from the system descriptions to the Radio Reference entries for the system, e.g. have a place where one can input the RR ID of the system.

During the install I get an error during the nginx install that says the htpasswd file is not found.

Whenever I fiddle with audio, and it's not something I can visualize directly (e.g. a gnuradio plot sink), then I'll go straight to an audio workstation/editor like Audition or Audacity.

These tools are not only great for audio analyses and mangling for testing, but they're also great for visual playback. Seeing periods of inactivity lets you seek forward to where there's audio activity again, or for visually identifying artificial alert tones - which are remarkably easy to pick out even in FTs of low sampling frequency.

Instead of the barebones audio player that exists right now, I believe having this same visual playback would be a wonderful creature comfort for end users, and one that's possible with this JavaScript library that I saw a few years ago: wavesurfer.js.

I'd imagine that modifying the player and adding this feature to just the currently chosen/playing audio is easiest, with a toggle for users to enable/disable this feature if the 8-16 kHz audio low resolution FFT is too taxing locally. This also has the benefit of no additional cost to server-side compute.

Maybe spectrograms could be generated for every call in the archive view with the FFT as a background of each call entry or something to that effect - but in order to keep processing local, this would require preloading of audio and that wouldn't be cheap on bandwidth, although it's not a far stretch from the bandwidth consumed from autoplayer-enabled views.

(Note, not necessarily asking you to do any work here - just opening this for discussion. I may try to implement this at some point, we'll see..)

Here in Minnesota, there is a statewide P25 system called ARMER, which almost all of the state uses for its emergency communications. There are then multiple simulcast sites. Within each site, you only get a small subset of the entire system's calls; I believe a site only gets calls for a given talkgroup if there is a radio that receives that talkgroup currently connected to that site. (There may be other roaming limits/etc too - but I know that officers can be halfway across the state and still receive the 'local' calls.)

Currently, there are two options to handle this in trunk-server:

1. Create a separate system for each site that you have a scanner for. This is the way people are currently setting things up with OpenMHz. It works - but it means you might have to browse a bunch of different systems to find a call or see if a call is available.
2. Set up one system for the overall P25 system, and have multiple sites upload calls to that system. I haven't tested this yet, but it should work in theory. The downsides I see are:

• No duplicate call handling -- duplicate calls will just show up multiple times.
• No ability to pick a specific site to listen to calls only from that site.
• The API key is the same for the entire system -- this is fine if you have one person managing all the scanners, but if you have multiple people, you're sharing credentials.

I'm thinking it would be nice to set up the ability to do a hybrid, sort of like what Broadcastify has done with Calls..

1. Add another tier under Systems called Sites. The Site would basically just be an API key for uploads; TGs/Sources would belong to the System.
2. Add some sort of duplicate call detection. I like the idea of just collapsing the calls detected as "duplicate" into a list, where you can still select from the calls that are available. This would avoid the behavior I see with BC Calls where sometimes the first call recorded is junk, but other sites that attempt to upload the call get denied because it's duplicate.
3. On the frontend, give the ability to listen to the entire system (with talkgroup filtering options/etc), or to select a given Site to listen to.

It appears that support for filter-type=unit was removed from the calls.js controller earlier this year, but references to this filter still exist in /backend/public/js/scanner.js and /backend/index.js. Is there a new way to filter calls by their srcList[i].src values?

It would be great to be able to upload a unit ID CSV file similar to talkgroups.

For example, an extract of a file I have locally:

3231425,BELGRAVE HEIGHTS - FS - Pumper/Tanker Portable 02
3231424,BELGRAVE HEIGHTS - FS - Pumper/Tanker Portable 01
3231338,BORONIA - FS - Vehicle 1 Portable 01
3231330,BORONIA - FS - Tanker 1 Portable 02

Seeing which units are involved in logged calls/filtering by them would be a useful feature where that data is available.

It's very hard to write a coherent description for a feed as it strips things like parenthesis, line feeds, and others.

For instance, if I type a feed title like this:

Puget Sound Emergency Radio Network (PSERN) Full

it becomes:

Puget Sound Emergency Radio Network PSERN Full

If I try to add line feeds to a feed description to separate out areas, they get removed putting all the text into one continuous blob. (Interestingly, line feeds are preserved if I edit the description, but parenthesis are stripped out completely.)

It looks like all of these characters get stripped when saving: ~!@#$%^&*()+=``~"'<>?/\|.

Surely there's a way to be less heavy-handed here by not stripping these characters out. (I'm assuming this is some sort of injection or XSS defense-in-depth, but there's plenty of mitigations for this that don't involve discarding user input.)

This is easily reproducible every few minutes, on a typical station with overlapping short and long recordings.

For example, 5:32:12 PM was left unread here:

What seems to be happening: Recordings are being sorted by start time, and older, longer recordings are inserted before the "now playing" entry that was finished and submitted first:

1. Receiver A starts recording at 5:32:12
2. Receiver B starts recording at 5:32:17
3. Receiver B finishes after 2 seconds, and uploads
4. Player starts playing from 5:32:17
5. Receiver A finishes after 12 seconds, and uploads