My client crash with a loop

Question

My client crash with a loop

Closed this issue 4 years ago · 22 comments

I have now all the logfiles and i can not find the reason for the crashes.
Advice me what you need more to help me.
asla.log
client.zip
multimon-ng.zip

Answer 1 · 2020-05-05T06:55:21.000Z

Hardware, OS, other Tools running? More info is always better ...

Answer 2 · 2020-05-05T09:36:16.000Z

I have changed to a Raspberry Pi 3b+ and run Rasbian 5.4.35-v7+. I use linein from a usb soundcard. Just the bw3 server and client running on this Pi.

Answer 3 · 2020-05-05T13:25:27.000Z

which SDR Dongle and which USB Soundcard?

Answer 4 · 2020-05-05T13:31:39.000Z

No dongle at all and a Chinese noname usb soundcard. I have got it to decode ones or twice but then something happens.

Answer 5 · 2020-05-06T05:48:13.000Z

Do you have this poblem only with line in or also with an sdr?
Maybe there's a alsa/performance problem at this point on a Raspi.
@janspeller can you also take a look into the logs, please?

Answer 6 · 2020-05-06T05:57:36.000Z

I have not tried BW3 with sdr. I use BW2 on another Pi with sdr and it works great. I will try to reinstall and see it that helps. In log it looks like the arecord crash also with overrun and i dont know what it is.

Answer 7 · 2020-05-06T06:01:36.000Z

Can you try this maybe? https://www.raspberrypi.org/forums/viewtopic.php?t=52390

And thats also interesting https://www.raspberrypi.org/forums/viewtopic.php?t=43738

Answer 8 · 2020-05-06T07:21:20.000Z

now i am trying --buffer-size=192000 (10s) if i am correct. To much but it was a suggestion on net. Not so much alarm here so it will take a while to get an error.

Answer 9 · 2020-05-06T12:53:59.000Z

No crash so far :) 3 alarms decoded. Buffersize seams to do the trick. Set 100000 now.
I read that someone use ffmpeg, maybe better then arecord?

Answer 10 · 2020-05-07T16:26:30.000Z

Today it crashed again. I increase buffer to 150000 now and start again.

Answer 11 · 2020-05-09T22:02:54.000Z

I give up. Nothing seem to help.

Answer 12 · 2020-05-10T08:02:22.000Z

Looks like a general problem to me. I think on a machine with more power this will not happen.
But i have no idea whats the exact problem here and what we can do to fix that - maybe someone other has an idea for that.

Answer 13 · 2020-06-04T03:19:41.000Z

Testing on a PI4 4GB now. Let you know if it works better.

Answer 14 · 2020-06-05T12:08:10.000Z

Workoing longer on the PI4, a few days, then same thing happens. And the watchdog is just looping. I think the watchdog has to be rewritten to kill the whole client, wait for 2 seconds and then start all over. The PID thing now dont work for me at all. And to the watchdog you should be able to connect the plugins too, so when it trigger the watchdog it is possible to get a notification in Pushover for example.

Answer 15 · 2020-06-07T21:19:22.000Z

I finally had some time to look into this.
If you didn't already, you might try using arecord with --buffer-time=1000000 instead of --buffer-size.

According to the also manual, buffer-time is in microseconds, so 1000000 would be exactly 1 second.

Answer 16 · 2020-06-08T03:08:30.000Z

Ok I have changed and started. The process manager need some work too because it just loop. I have try to add a stop argument before try to start again.

--- Med vänlig hälsning Stefan Rydberg 0767-882514 2020-06-07 23:20 skrev Jan Speller:

I finally had some time to look into this. If you didn't already, you might try using arecord with --buffer-time=1000000 instead of --buffer-size. According to the also manual, buffer-time is in microseconds, so 1000000 would be exactly 1 second. -- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or unsubscribe [2].

Links: ------ [1] #44 (comment) [2] https://github.com/notifications/unsubscribe-auth/ACZQYV25GI7E34E54JJ5HJ3RVP76NANCNFSM4MYYQ4IQ

Answer 17 · 2020-06-08T05:45:29.000Z

The process manager need some work too because it just loop.

What do you mean, exactly?

Answer 18 · 2020-06-08T06:32:18.000Z

When the processmanager thinks that arecord or multimon is down it tries to restart them, but then it ends up in a loop. I have not dig into this but yesterday when the client crashed it filled up my sdcard with logs.When i notised i empty the log folder and restart the client again. I hope i explained it more clear now :D The client still works with the new settings. I hold my thumb.

--- Med vänlig hälsning Stefan Rydberg 0767-882514 2020-06-08 07:46 skrev Bastian Schroll:

> The process manager need some work too because it just loop. What do you mean, exactly? -- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or unsubscribe [2].

Links: ------ [1] #44 (comment) [2] https://github.com/notifications/unsubscribe-auth/ACZQYVZ2AXFH73STPOCUH4DRVR3INANCNFSM4MYYQ4IQ

Answer 19 · 2020-06-10T09:17:30.000Z

I finally had some time to look into this.
If you didn't already, you might try using arecord with --buffer-time=1000000 instead of --buffer-size.

According to the also manual, buffer-time is in microseconds, so 1000000 would be exactly 1 second.

Still crash and filled up my sdcard. I had made some changes to the "watchdog" so maybe next time i can read the logs.

Answer 20 · 2020-06-12T08:47:18.000Z

Still no luck. Crash and fill up sdcard. I will stay with BW2.

Answer 21 · 2021-01-08T19:33:30.000Z

@sm7tix maybe this is fixed with #64 from @janspeller ?

Answer 22 · 2021-01-09T05:17:21.000Z

I am sorry but i cant try it out. No external soundcard available.

--- Med vänlig hälsning Stefan Rydberg 2021-01-08 20:33 skrev Bastian Schroll:

@sm7tix [1] maybe this is fixed with #64 [2] from @janspeller [3] ? -- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [4], or unsubscribe [5].

Links: ------ [1] https://github.com/sm7tix [2] #64 [3] https://github.com/janspeller [4] #44 (comment) [5] https://github.com/notifications/unsubscribe-auth/ACZQYV4G4CRGP3JFF7Z4S6TSY5MZTANCNFSM4MYYQ4IQ