firefox last rev gives chopped audio\waterfall on win7pro32b [fixed with browser site data clear]
HI, just switched my KIWI now with v1.170 OS after some months and on Firefox (last rev) the audio+waterfall are running "chopped"
with audio underrun in the stats.
On Chrome all is ok.
OS is Win7pro32b
Any suggestion on how resolve that ?
73
Phil_IC8POF
with audio underrun in the stats.
On Chrome all is ok.
OS is Win7pro32b
Any suggestion on how resolve that ?
73
Phil_IC8POF
Comments
73
Phil_IC8POF
I see this bug happening on FF 87.0, 64 bit (Win7 Ultimate 64 bit SP1) - and it annoys me a lot.
I use KiwiSDRs at least twice a week. If this bug happens and gets severe enough, it can trash IQ recordings.
The KiwiSDR UTC clock also lags behind actual time when it happens. When this fault occurs, after a couple of hours both the audio and the clock can be behind by something like 20 minutes.
This problem appears to happen on the Bjargtangar KiwiSDR more often than other Kiwis I use.
If I see it happen again, is there anything in particular that I should check? (Like in Firefox Web Developer tools..)
Clearing site data in the browser didn't seem to help.
Let me know if you want any of the glitched IQ recordings. I have a few of them saved.
@DazDSP you spotted that was a three year old thread?
There have been Chrome issues (known bug, now cleared) on Win10 recently but Firefox was normally OK.
Try another browser, mention what OS you run, see if anyone else can replicate your issue.
I don't think Chome 90 (with the fix) has actually been released yet.
Given the age of this thread I'm going to un-announce it..
OK and I missed the OS was mentioned already (Doh) but this is Firefox so seems strange that most people with Win10 issues found FF OK.
@Powernumpty It makes no difference how old the thread is, if the problem hasn't been found and fixed. It's a problem that strikes every once in a while, and things mostly work so you put up with it, and wait for it to be fixed.
The bug can't be replicated easily, because it appears to strike at random. Most people probably reload the page or try another kiwi. But for my uses I can't do that, because the recordings I make with the kiwis are important - and most times they turn out ok, or are usable with edits.
I've been recording at least 3 hours of content a week for over two years now, so I've seen the bug happen many times, despite browser and kiwi updates.
I could try another browser, but as you just mentioned this may introduce yet other bugs (that may be even worse).
So how about addressing the question - Is there any information in the FF Web Developer tools that might be helpful to identify what's going wrong when this bug happens?
@DazDSP OK I see now, the recent Win10+Chrome popping issues made me think perhaps it it was similar, so a more fruitful path would be to look at that current thread than an older issue that didn't seem to be provoking recent traffic. It was also pre-first coffee so no offense intended.
There is a pretty wide range of other influences that could affect this and if it can't be easily replicated it makes fault finding hard so I'm not sure focusing on the browser diagnostic is the best first path. What I'd do is snapshot what other software is running at the time, if the network is loaded, time since last reboot, RAM use and any VOIP software running (Q.O.S). As the PC is Win7 how heavily dust loaded are the cooling fans, has the RAM or PCI cards been re-seated recently etc.
Any information like "worse if antivirus doing weekly scan" helps, sometimes "knowing" the issue is the browser stops us gathering data that could help.
I'd run "ping -t thesdr.url" while you do a longish recording, see if the link gets variable, also a "tracert thesdr.url" see how torturous the path is.
I have a win7 Ultimate box with Firefox on, not been run for a while but I'll see if I can get it to glitch (from the UK).
OK.. This might be useful then...
I usually have more than one Kiwi window open (often 4), and normally just one of them will have the bug. The rest will continue working just fine.
I think the fact that the Kiwi UTC clock lags behind along with the audio must surely be a big clue. (That's why I posted this - I only just noticed the connection the other day.)
As to your questions:
Virus scans are scheduled for 2AM, so it never happens during my normal Kiwi sessions.
CPU temps are OK, and I normally close as many other apps as I can to free up memory for recording.
Nothing has been reseated recently, but everything else is working fine so there is really no valid reason to take the system apart.
No VOIP software.
I could try the pings, but normally I try to minimize network use during recording.
Firefox running ~4 Kiwi's (how many other tabs), from task manager how much memory is Firefox using?
From that description my process of elimination would be to reboot, fire up the main Kiwi's you use (note in what order) then start the recording, have task manager running so you can check the RAM is not creeping up while it runs. If Pings are too much traffic then I think we might have other issues, at least if you proved ping does cause issues that is all more evidence to help, just "not doing that" is like making the issue harder to find.
Also things like lower the waterfall rate on other tabs, keep Spectrum off, if you have multiple large monitors go to just one for the duration of the test. To me the goal is to reduce external factors and get to the stage where you can replicate it. It is quite possible Firefox on that computer simply is too close to its limit with four stations at the same time with some features/modes.
Increase stations see if you can provoke it that way so we know what is "too much" (note modes), the browser is doing quite a bit on some modes/extensions so all will have a finite limit, we just want to know how to not run too close to that one's limit assuming there is not some memory leak issue.
You could I suppose forgo the browser and use kiwiclient for the recording, if you know what you want to record before you start that is. Browsers are great for pretty pictures but having a bit of code that is focused on the task and nothing else should show where any breaks come in.
Stu
I do monitor RAM use but it always creeps up because it records to blob memory.
I can run the ping test if you like.. But I have some more info:
A friend of mine has just told me a few minutes ago that she sees this same Kiwi problem happen in Chrome.
It often takes quite some time before the problem starts - but not always.
On Thursday I made two one-hour recordings on a KiwiSDR in Missouri. The live audio started glitching almost immediately after connection. The first hour of IQ recording saved OK with no obvious glitches. The second hour of IQ recording was glitch-free until 48 minutes in, but after that it had random glitches until I saved it and disconnected.
That Kiwi window was so lagged near the end I was unable to reset the timeout, so I connected to that same Kiwi again using a new window and I saw that the first instance had already timed out and disconnected - even though it was still playing delayed and broken audio and updating the waterfall.
I'll have to get back to you with the RAM figures etc..
I have run 6 or 7 Kiwi windows at the same time - all recording - but not for a long time (I check signals and close the ones with the worst noise levels). The system seemed to handle it OK.
kiwiclient may be a good option, but I'm not sure if it can be monitored while recording..?
How much RAM does the PC have, SSD or Spinning disk for the swap file(s)?
Thinking about how large are the recordings? I.Q. for hours must be pretty big.
My comment on RAM use was based on Firefox at various times having slowed down but it was normally with a big bunch of RAM held and freed up after being closed and reopened. Here you are really inviting that sort of issue, might even be disk swapping.
I'm sure there are people on here who can help with KiwiClient, I've not used it much except indirectly with other software.
It does feel like the issue is two parts 1. Monitoring, 2.Recording.
I wonder if the new camping feature could let you listen to an ongoing Kiwicleint recording at the same time, that could give both requirements.
6GB RAM, SSD with swapfile on it.
The IQ recordings are typically a max of about 350 megs each for two hours. The RAM appears to swap out as the recording progresses.
This problem seems less related to the recording duration than to the particular KiwiSDR being used.
The 2-hour long recordings (in one piece) that I make every Sunday rarely have any issues. But they are from different SDRs than the two 1-hour recordings that are done on Thursday.
The Bjargtangar and Missouri Kiwis seem to most often have this problem.
Well there could be network issues on the problem paths, I'm not sure where you are in the world but I see some people connect in to my SDR and get issues and leave not long afterwards, not all of the internet is routed robustly with the same type of media/brand of switch and the more desirable radio location may only have one connection feeding it for some distance.
But surely a slow network connection wouldn't slow down the UTC clock on the Kiwi?
And what about the browser still receiving data 20 mins delayed, and after it had already disconnected? Surely the network would never buffer that much data...
I'm in Australia by the way. My friend who observed the same problem on Chrome is in the UK.
Chrome is a different issue - see other recent threads on Win10 popping.
Not sure you could find an SDR further away than Iceland, well done ;-).
Joking apart that is a few fiber links and lot of ms delay just for a simple connection. I'm not sure the packet size used for this, or how OpenWebRX retries but a single blackhole router that dislikes a few packets is going to wear over a long recording.
I'll bow out now as I can feel this drifting off to too many maybe's and further from a traceable Firefox issue.
BTW 6G RAM is OK on Win7 but if you could find some reasonable I'd push it up a bit, my last one had 12G and used a surprising amount of that, you might find FF us using 40%-50% of your ram and Windows claims the rest. Also sometimes a 4G +2G (assumed) is not as good as 4+4G of the same type.
I think I'm going to take Windows off the list of supported operating systems 😕
Ha one of the few reasons I kept a Windows box going was for a couple of Windows only SDR programs and my flex 1500 (that I never use). I hear talk of replacing the kernel with Linux, makes sense.
@DazDSP I'd use kiwiclient for the kind of monitoring you are doing.
I agree with Christoph. Take the vulnerabilities of the browser, virtual audio cable, etc. out of the recording equation using kiwiclient/kiwirecorder. You can still monitor in parallel with a browser connection. But any problems there shouldn't effect the recording.
I looked at the Bjargtangar Kiwi a bit. It's configured for 8-channels and has 2 WSPR autoruns. So there is some possibility the Beagle could be overwhelmed if there were many concurrent connections. And that might be a source of audio problems.
The clock looked okay. This Kiwi has GPS setup. So GPS monitors the clock and corrects it if it is more than a few seconds off GPS time. This is important for WSPR of course. It also means I can look back in the log for GPS clock corrections. Since March 23 there were 24 corrections. Most were less than 5 seconds. But one was 60 secs after the Kiwi had been running for 23 hours (so not a startup issue). So that's kind of odd. Maybe there is a bad NTP time server someplace feeding it bad data? Seems unlikely.
This business about getting behind by 20 minutes makes absolutely no sense. There's not that much buffering anywhere along the path.
What does the GPS Az/El map look like for that site? Most birds must be low down?
I agree with Christoph. Take the vulnerabilities of the browser, virtual audio cable, etc. out of the recording equation using kiwiclient/kiwirecorder. You can still monitor in parallel with a browser connection. But any problems there shouldn't effect the recording.
There are many resources here on how to use kiwiclient/kiwirecorder for monitoring. If you have questions/suggestions here's the right place to ask.
The az/el plane doesn't look that bad, except that there is obviously some az blocking (e.g. side of a building in the way) such that it has reception az of maybe 160/360 degrees.
But that alone is not going to cause significant errors in time solutions. Position yes, but time no. (1km ~= 3.3us) Christoph's Kalman filter gets rid of all the outliers anyway.
Regarding KiwiClient:
KiwiClient would be a great way to record, though if the signal can't be heard live simultaneously that could be a problem in some applications.
Even better if KiwiClient can save the waterfall and s-meter data as well as the IQ data. That would be ideal for one of my applications - though I'd need to find a way to replay it later. Currently I'm using video screen capture instead, and it's demanding of the system but it is trouble-free and everything works fine.
I have tried Kiwiclient a long time ago - but the kiwi it was on timed out, ruining one recording. That can probably be avoided now.
Regarding dropouts and delay:
Bjargtangar is 15 hops from me currently
Missouri is 17 hops from me currently
That doesn't seem excessive, but it could change. When tested for a few minutes, they were both working fine.
My friend in the UK says the Win10 popping was a separate issue that affected all Kiwis except those running older software.
Whereas this bug she described as "Time falls behind, waterfall lags, audio stops and starts and it's a mess". This is the bug I have been seeing occasionally for a long time now.
She will gather more data and comment here.
On Thursday when I noticed how far behind the affected Kiwi audio was, I had a good look at what was happening. That's when I noticed the UTC clock was delayed.
Then when I connected a second time to the same Kiwi using a new window, it was clear that the Kiwi was functioning OK (correct UTC) and it showed my first connection had already timed out and disconnected - but the first browser window was still playing (broken) audio and showing new waterfall data (the waterfall was start/stop). This suggests that the first browser window was somehow (wrongly) caching all the incoming data for far too long, or maybe it's buffer playback was stalling.
Well, on April 10 I ran an hour long test with ALL FOUR Iceland Kiwis running at the same time, (plus a couple of other Kiwis for good measure) and had a total of 12 Firefox browser windows open including Facebook and Twitter, plus IE and Skype also... and I couldn't make it break. Everything worked just fine.
Memory usage was through the roof, and the system happily swapped out to the SSD.
Since complaining about this issue here, I haven't noticed the glitching problem recur on those particular Kiwis I mentioned - even though I've used them a lot since.
There are still cases where other Kiwis have shown severe glitches in IQ recordings. The most recent was on July 10 on the Isokyb, Sardinia SDR - but I didn't get a look at the UTC clock to see if it was lagged.
That's all I can add for now.
This problem I've described appears to happen when the particular KiwiSDR has it's internet connection overloaded (too much data to send for the available network bandwidth). It typically happens with a higher number of users, and only on certain KiwiSDRs. It does not appear to be browser related. It appears to be due to low network bandwidth, so it's unlikely to be a KiwiSDR bug.
Back in April 2022 I ran a test when I observed this problem, and observed something interesting.
The problem Kiwi was connected to using the MS Edge browser. After one hour, the KiwiSDR clock and the radio program time were both 20 minutes behind reality.
Eventually, I calculated that the KiwiSDR connection should have timed out because it had exceeded it's maximum idle time - but that was delayed also.
So, while the first connection was still receiving data in Edge, I connected to the same Kiwi again using Firefox.
The new Firefox connection showed that the first connection in Edge had already timed out and disconnected from the SDR. But there it was in the Edge browser - still receiving data!
So I opened Resource Monitor to check - and sure enough the data was still coming in from the Internet to Edge.
So somehow the data stream from the Kiwi was being delayed for huge amounts of time between the KiwiSDR and the destination.
As hard as this might be to believe, this means that in this particular case something like 56 meg of data was getting buffered somewhere in the total path.
The data was mostly unusable though. There are frequent glitches when the delay gets much more than a few minutes. If the delay doesn't get too high and the number of SDR users reduces, the data catches up, things return to normal, and the saved data is good.
So it seems this particular issue probably isn't a KiwiSDR bug, but rather a symptom of low internet bandwidth.