OpenMHz: No playback in Mozilla based browsers?

[GTR8000]

Apologies if this has already been covered, didn't find anything in a search.

OpenMHz works great in the Chrome desktop browser, but not in any Mozilla based browsers (Firefox, Waterfox, etc.) Is this a known issue where it simply doesn't like the m4a file format?

[rpdale]

Within the past few weeks it has stopped working for me on Safari on my iPad. The website doesn’t load at all.

On Jan 31, 2020, at 6:18 PM, GTR8000 notifications@github.com wrote:

 Apologies if this has already been covered, didn't find anything in a search.

OpenMHz works great in the Chrome desktop browser, but not in any Mozilla based browsers (Firefox, Waterfox, etc.) Is this a known issue where it simply doesn't like the m4a file format?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[GTR8000]

I'm also noticing in Chrome that the page is not auto-scrolling up as new transmissions come in. Every couple of minutes I've got to scroll up manually to get back to the most recent calls.

Also a small request...would it be possible to add the Date column to the list of calls? It would make it a lot easier when browsing the archives or scrolling all the way down.

Thanks, awesome software and interface!

[robotastic]

I actually have been lazy and haven't tested with Firefox. I will download and test.

I use OpenMHz on Safari iOS on my iPhone, but I will give it a try on my iPad.

On Jan 31, 2020, at 6:18 PM, GTR8000 notifications@github.com wrote:

Apologies if this has already been covered, didn't find anything in a search.

OpenMHz works great in the Chrome desktop browser, but not in any Mozilla based browsers (Firefox, Waterfox, etc.) Is this a known issue where it simply doesn't like the m4a file format?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/297?email_source=notifications&email_token=AAA3TXFUA7OK3QUN4EB3K6LRASWVFA5CNFSM4KOO6BOKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IKI4FTA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA3TXADWHZO5UAMKDXPFZDRASWVFANCNFSM4KOO6BOA.

[robotastic]

Hmmm... I just fired up Firefox on OSX and it seems to work fine. It looks like Firefox support is dependent on OS support. https://caniuse.com/#feat=aac

What OS are you using?

[GTR8000]

Windows 10.

This was also an issue with the recent Broadcastify implementation of a very similar website. The audio clips would not play until Lindsay Blanton "wrapped the audio in audio tags".

I believe this is the issue in Firefox, as noted on caniuse.com:

Partial support in Firefox refers to only supporting AAC in an MP4 container and only when the operating system already has the codecs installed.

[GTR8000]

It appears that this is only an issue with certain systems, while others play the audio (live and archives) just fine in Firefox. Perhaps an encoding issue on the devices running Trunk Recorder?

A few examples...thanks!

Working: Washington Metropolitan Area Transit Authority DC Fire and EMS

Not working: Alexandria VA Fairfax County Project 25

[robotastic]

Interesting! I am running both WMATA and DCFD using a branch that use FDKAAC to generate the files instead of FFMPEG. I will try to get that branch merged in.

[GTR8000]

I'm going to close this ticket, as fdk-aac seems to have done the trick. Thanks!