Value error cannot convert float NaN to integer

[champquestion]

Hierbij roep ik hulp in omdat onderstaand python script vast loopt.
Ik hoop dat julle me kunnen helpen met deze foutmelding (zie onder) en dat deze post voldoende info biedt.
mvg

relevante hardware/ software/script

asus laptop k55vd-sx416h
OS ubuntu 20.04.2 LTS
webcam als microfoon logitech C310
geinstalleerd : sox lame python3-matplotlib, python3
script: slowrunner /noise_level_protocol van Github. Bestaat uit 5 scriptjes. Dit script betreft mydetect.py

Dit script onderdeel is bedoelt om dagelijks geluid te meten en op te slaan, en later in een ander script te verwerken tot een degelijkse grafiek.

Als het script loopt zie ik dit :

Listening for 30 seconds...
Measured values - peak: 0.036346 rms: 0.008807 == peak: 53 dBA / rms: 52 dBA
00:02:07 Sound detected - save compressed audio: /home/henk/Bureaublad/nlptestusb/audio/20210519/20210519-000207-53-52.mp3

Na verloop van tijd onstaat deze foutmelding :

Listening for 30 seconds...
arecord: pcm_read:2178: leesfout: Invoer-/uitvoerfout
Traceback (most recent call last):
File "mydetect.py", line 150, in <module>
ext_rms = int(round(rms_dBA, 0))
ValueError: cannot convert float NaN to integer

Verder krijg ik nog een warning m.b.t. regel 28 : unused call imported from subprocess.


Wat ik al gevonden of geprobeerd heb:
overbodige spaties verwijderd.
Op intenet zoeken naar de foutmelding . Het script laten lopen en ook in Thonny naar de variabelen gekeken maar deze kon ik helaas niet hier na toe kopieren.
(Ben een beginner qua programmeren , wel boekje gelezen en hierin wat korte oef gedaan over python.)

Python: detect.py

*snip*

[ Voor 71% gewijzigd door RobIII op 19-05-2021 16:53 ]

[DataGhost]

Als je de foutmeldingen leest zie je dat het fout gaat in arecord. Het is leuk dat je subprocess calls doet maar je moet wel controleren of die goed gaan. Lijkt me logisch dat je verderop in je script dus niks nuttigs meer kan doen.

[RobIII]

Wanneer je code post verwachten we dat je relevante(!) code post en dat houdt in geen 194 regels dumpen en ons laten zoeken naar 't probleem. Zoals ik je eerder al eens heb aangegeven: Debuggen: Hoe doe ik dat?. Heb je dat al eens gedaan? Print/echo desnoods wat variabelen tijdens runtime naar je scherm/een logfile zodat je kunt kijken of alles ook bevat wat je denkt dat 't moet bevatten.

champquestion schreef op woensdag 19 mei 2021 @ 16:14:
Wat ik al gevonden of geprobeerd heb:
[...]
Op intenet zoeken naar de foutmelding .

Wat kwam daar uit?

champquestion schreef op woensdag 19 mei 2021 @ 16:14:
Het script laten lopen en ook in Thonny naar de variabelen gekeken maar deze kon ik helaas niet hier na toe kopieren.

Dan type je 't toch over of, in 't allerergste geval, maak een screenshot? En wat waren je bevindingen daarvan? Deze informatie voegt, voor ons, helemaal niets toe

[ Voor 59% gewijzigd door RobIII op 19-05-2021 16:58 ]

[champquestion]

Hallo Robill
Ik heb Thonny geinstalleerd en daar heb ik nu op debug gedrukt.
ik post het als er iets uit komt. Oke ? Sorry ik moet nog even wennen aan het proces.

[RobIII]

champquestion schreef op woensdag 19 mei 2021 @ 16:58:
Hallo Robill

champquestion schreef op woensdag 19 mei 2021 @ 16:58:
Sorry ik moet nog even wennen aan het proces.

Geeft niet, het is gewoon dat we hier niet van handjes vasthouden houden We verwachten gewoon dat je zélf zoveel mogelijk doet en in je topicstart zet zodat wij onze tijd niet hoeven verdoen met dingen aandragen die je al lang gevonden of geprobeerd hebt

Overigens is de eerste plek voor vragen natuurlijk de GitHub issues pagina van het betreffende project waar je gewoon de maker(s) zélf vragen kunt stellen

[ Voor 14% gewijzigd door RobIII op 19-05-2021 17:05 ]

[CH4OS]

Kleine hint die je kan helpen: NaN staat voor Not a Number.

[champquestion]

Dank voor de tip om de maker zelf te mailen. Zal proberen om deze te bereiken.

(als ik de variables van het script bekijk in thonny op het moment dat het script stopt
ziet er uit alsof sommige waarden ineens op 0 staan.)

[Morrar]

Misschien nog wat tips:

- Die regel 28 kun je verwijderen; nergens wordt call gebruikt. De auteur heeft dit waarschijnlijk vervangen door subprocess.call en subprocess wordt al op regel 26 geimporteerd. Heeft verder geen impact op de fout overigens.

- Verder staat NaN inderdaad voor een ontbrekende waarde; wellicht hapert er iets in de hardware waardoor deze ontbrekende waardes ontstaan.

- Op regel 150 wordt iets afgerond en naar integer geconverteerd: ext_rms = int(round(rms_dBA, 0)). Als de waarde voor rms_dBA ontbreekt loopt die int conversie mis.

- Je zou kunnen checken op ontbrekende waardes en bijvoorbeeld een 0 kunnen invullen als je ze tegenkomt. Dan omzeil je de foutmelding, maar het onderliggende probleem blijft wel bestaan natuurlijk.

Verder ziet het script als geheel er sowieso wat rommelig uit...

[ Voor 12% gewijzigd door Morrar op 19-05-2021 22:11 ]

[DataGhost]

champquestion schreef op woensdag 19 mei 2021 @ 16:14:
arecord: pcm_read:2178: leesfout: Invoer-/uitvoerfout

Nogmaals dan, omdat het ondergesneeuwd raakt... je kan het script blijven fixen wat je wilt maar dit lijkt me de oorzaak. De auteur van het script kan verder ook niet zoveel meer, behalve hierop controleren en geen output geven omdat er geen input is.

[Rmg]

champquestion schreef op woensdag 19 mei 2021 @ 16:14:

Listening for 30 seconds...
arecord: pcm_read:2178: leesfout: Invoer-/uitvoerfout
Traceback (most recent call last):
File "mydetect.py", line 150, in <module>
ext_rms = int(round(rms_dBA, 0))
ValueError: cannot convert float NaN to integer

Float NaN houd in Not a Number.
De float naar integer conversie faalt.
Waarschijnlijk omdat rms_dBa niet gevuld is.
En dat komt waarschijnlijk door dat je pcm_read.

Je kan een aantal dingen doen.
Voor de conversie checken of rms_dBa wel of niet NaN is ( math_isnan() ) en dan de conversie niet uitvoeren.

Try catch om je conversie, zodat je het probleem kan afvangen en alsnog kan doorgaan

Uitzoeken waarom die PCM Read failed en het onderliggende probleem oplossen.

[champquestion]

Bedankt voor alle tips. Moet het even laten bezinken.
Nog geen bericht van de maker. (maar misschien komt dat ook niet meer)
ik had gisteren nog deze schermen geprint. Als Robill mij toestaat deze te posten :
Ik denk dat die goed in jullie verhaal passen.
Zal ook regel 28 uit het script gaan verwijderen. Geloof dat ik nog niet alles begrijp van jullie tips
maar ga me erin verdiepen.

[RobIII]

champquestion schreef op donderdag 20 mei 2021 @ 12:04:
Als Robill mij toestaat deze te posten :

Nogmaals:



Mijn naam is RobIII, niet Robill.

champquestion schreef op donderdag 20 mei 2021 @ 12:04:
Nog geen bericht van de maker. (maar misschien komt dat ook niet meer)

Euh, je hebt 5 uur na je issue een reactie gehad hoor En dat is overigens verdomd netjes en snel. Daar gaat soms dagen of weken overheen als je al reactie krijgt.


In je eerste screenshot zie je dat rms_dBA, zoals ook uit je foutmelding blijkt, NaN is. Zover waren we al (hell: de foutmelding geeft 't letterlijk aan ). Vervolgens ga je kijken hoe dat komt en ga je dus met debuggen kijken naar wat er een stukje éérder gebeurt. Bijvoorbeeld op de plek waar rms_dBA geset wordt. Kijk wat daar gebeurt, of in alle variabelen iets zit dat met je verwachtingen overeenkomt en, zo nee, hoe dat dan weer komt. Kwestie van 't "spoor" terug volgen tot aan de bron.

[ Voor 35% gewijzigd door RobIII op 20-05-2021 12:59 ]

[champquestion]

Bedankt RobIII voor het kijken , ik had zelf ook al gekeken maar kennelijk niet op de juiste plek.
Ik ga met de maker asap in gesprek en antwoord geven op zijn vraag

[pedorus]

champquestion schreef op donderdag 20 mei 2021 @ 12:04:
Zal ook regel 28 uit het script gaan verwijderen. Geloof dat ik nog niet alles begrijp van jullie tips
maar ga me erin verdiepen.

Dat lost niks op, maar je krijgt wel afwijkingen in regelnummers, dus zou ik niet doen (of anders leegmaken). Als ik het goed zie gaat het 2x goed. Enkel de derde keer krijg je uit "sox " + wavfilename + " -n stat" een amplitude van 0.0000 en een rms van NaN (wat dan vrij logisch is). Mijn vermoeden is dat er een zekere filtering met een drempelwaarde is of dat het luisteren soms niet goed lukt? Misschien moet je gewoon wat meer geluid maken? Of, wellicht draait het door, een ifje neerzetten voor als peak_amplitude 0 is?

[ Voor 7% gewijzigd door pedorus op 22-05-2021 00:28 ]

[champquestion]

Dank voor de tip.
Ik heb de maker script nog gevraagd of er wellicht waarden kunnen zijn die te laag zijn om er iets mee te doen.
Vandaag getest op andere pc. Zelfde verhaal. Script kan een hele tijd goed draaien maar na verloop van tijd krijg ik dan weer die foutmelding:

Listening for 30 seconds...
-nan
0.000000
Traceback (most recent call last):
File "/home/henk/noiselevelprotocol/mydetect.py", line 152, in <module>
ext_rms = int(round(rms_dBA, 0))
ValueError: cannot convert float NaN to integer

Weten jullie wat het getal 30 in de volgende regel betekend ?
Is dat 30 seconden ?

if int(dur) >= 30: time.sleep(1)

Of ik moet de tijd oprekken en het script meer tijd geven om met een werkbare waarde te komen
of ik moet inderdaad iets tussenvoegen waardoor het script weer overnieuw gaat lopen.
Hoe ik dat laatste het beste kan doen weet ik niet.

[pedorus]

Het probleem is dat je eigenlijk in het verkeerde forum zit, want je bent niet echt zelf bezig met softwareontwikkeling. Maar een oplossing is waarschijnlijk vrij simpel, 0.0 krijgen ipv NaN. En dat kan bijvoorbeeld door regel 146 aan te passen door iets wat rekening houdt met 0 geluid:

Python:

        rms_dBA = 0.0 if peak_amplitude <= 0 else d_rms + (a_rms - d_rms)/(1 + (rms_amplitude / c_rms)**b_rms)

Geen idee of het werkt natuurlijk, en je kunt het hebben over of rms_dBA dan 0.0 moet zijn. Het mooiste zou zijn als je dit kan testen en als het werkt daar een pull request voor kan doen op dit project. Mooie oefening met github

Mijn vermoeden is dat je met een goede microfoon nooit 0 geluid hebt, dus dat de programmeur dat nooit gehad heeft.

[champquestion]

Dank voor de aanbeveling. Helaas werkte het niet.
Moet misschien verder terug.

Ik wilde voordat ik een betere en duurdere mic ga halen zeker zijn dat het ook goed werkt , vandaar deze
exercitie.

Ik begrijp deze regel niet m.b.t. sox, met name het gearceerde gedeelte.

sox_peak = subprocess.getoutput("sox " + wavfilename + " -n stat 2>&1 | grep 'Maximum amplitude' | cut -d ':' -f 2")

Dit is wat ik tot nu toe heb kunnen achterhalen:

subprocess.getoutput, run a command in a shell and get its string output (as opposed to byte string output). Then you can split on whitespace and grab the first element from the returned list of strings.
-n = -n’ option is used to specify the input file as null file .
Using a null file to output audio amounts to discarding the audio and is useful mainly with effects that produce information about the audio instead of affecting it (such as noiseprof or stat).
cut = remove sections from each line of files
cut -d = use DELIM instead of TAB for field delimiter (= scheidingsteken)
Stat = The "stat" effect produces statistical information about the audio data
-f, --fields=LIST = select only these fields; also print any line that contains no delimiter character, unless the -s option is specified

[ Voor 116% gewijzigd door champquestion op 26-05-2021 14:46 ]

[DataGhost]

Volgens mij heb je nog steeds niet gekeken wat er precies in het csv-bestand staat als het misgaat. Je kan (nogmaals) wel van alles gaan aanpassen in het script zodat 'ie niet meer crasht bij ongeldige input, maar dat wil niet zeggen dat je er dan wel geldige output uit gaat krijgen (of überhaupt iets bruikbaars). Dat is wel netter natuurlijk, maar allemaal symptoombestrijding.

[champquestion]

Dit is het laatste deel van het csv bestand voordat het script crashte om 13:19:05


time,Loudness Peak(dBA),RMS Loudness(dBA)
2021-05-26 13:15:08,35.6,35.6
2021-05-26 13:15:38,36.1,36.1
2021-05-26 13:16:07,36.9,36.9
2021-05-26 13:16:37,40.7,40.7
2021-05-26 13:17:07,35.6,35.6
2021-05-26 13:17:37,37.5,37.5
2021-05-26 13:18:06,35.9,35.9
2021-05-26 13:18:36,38.3,38.3
2021-05-26 13:19:05,52.6,52.6

[ Voor 4% gewijzigd door champquestion op 26-05-2021 15:08 ]

[DataGhost]

Ja dat heb ik dus verkeerd gelezen denk ik, het gaat om de wav-file, dat is de input. De csv-file is de output, pas nadat processing gelukt is, dus als daar wat in staat is het sowieso iets nuttigs. De wav-file is waarschijnlijk leeg of er gaat iets anders met sox mis (waar niet op gecontroleerd wordt en waarvan ik de output ook niet zie), en dikke kans dat dat al in de arecord-stap misgaat (zoals in je startpost) wat op hardware zou kunnen wijzen. Probeer dus eens

sox naam_van_laatste_bestand.wav -n stat

en kijk eens wat de output daarvan is. Waarschijnlijk iets wat ervoor zorgt dat rms_amplitude 0 of NaN wordt.

[ Voor 4% gewijzigd door DataGhost op 26-05-2021 15:29 ]

[champquestion]

De wav is niet af te spelen en slechts 44 byte.
Er wordt niets uitgelezen ?


sox 20210526-131935.wav -n stat

sox WARN wav: Premature EOF on .wav input file
Samples read: 0
Length (seconds): 0.000000
Scaled by: 2147483647.0
Maximum amplitude: 0.000000
Minimum amplitude: 0.000000
Midline amplitude: 0.000000
Mean norm: -nan
Mean amplitude: -nan
RMS amplitude: -nan
Maximum delta: 0.000000
Minimum delta: 0.000000
Mean delta: -0.000000
RMS delta: -0.000000
Rough frequency: -2147483648

Probably text, not sound

[DataGhost]

Dus eigenlijk wat ik al zei in de allereerste reactie op je topicstart. Dan wordt het dus eens tijd om uit te zoeken wat de output van de arecord-calls allemaal is als er geen "arecord: pcm_read:2178: leesfout: Invoer-/uitvoerfout" vlak aan je crash vooraf ging. Liefst dus zonder --quiet. En misschien is het .wav-bestand wel gewoon text dus daar kan je ook nog eens in kijken.

[ Voor 17% gewijzigd door DataGhost op 26-05-2021 15:54 ]

[champquestion]

super bedankt.
dat is wat je noemt een omweg nemen
maar ik moet wel zeggen dat ik hierdoor wel flink wat bij geleerd heb.
erg mooi om te weten dat het in de arecord call al mis gaat.
ik ga me in arecord verdiepen en kijken of ik hier meer info over uit kan halen.

ps dit staat er in de wav bestand , slechts 1 regel:

RIFF`(\00WAVEfmt \00\00\00\00\00\80\BB\00\00\00w\00\00\00data\F0_(\00

[ Voor 19% gewijzigd door champquestion op 26-05-2021 16:03 ]

[pedorus]

Het is duidelijk een andere fout inderdaad, maar eigenlijk is het scriptje ook niet heel handig in dat het fouten negeert. Een snelle, slechte fix voor regel 121 is waarschijnlijk iets als:

Python:

        while subprocess.call("arecord -D hw:1,0 -d " + dur + " --fatal-errors --buffer-size=192000 -f S16_LE -r48000 -c1 --quiet " + wavfilename, shell=True) != 0:
            import sys
            print("arecord call failed, retrying...", file=sys.stderr)

Dat is alsnog lelijk, want veel retries, en het gebruikt de shell onnodig en geeft injectie als wavfilename een spatie bevat bijvoorbeeld.

Random arecord problemen lijken vaak te komen door een traag filesystem of andere installatieproblemen, gebruik je toevallig geen xfs als filesystem en zou je misschien xfs als filesystem kunnen proberen?

[champquestion]

@pedorus ,erg bedankt voor deze code / oplossing !

Heb het net getest en het lijkt tot dusver prima te werken.
Het nadeel is wel dat er af en toe wat gaten vallen. Maar als het daar bij blijft dan moet dat maar en misschien met een betere microfoon e.d. is dit wel minder.

Ik begreep eerst de != 0: niet, omdat dit in Python, niet gelijk aan, betekent.
Maar in de shell het dus kennelijk, false, betekent.
(Als ik nu onzin uitkraam dan hoor ik het graag.)

Ik heb momenteel geen xfs draaien als filesystem. Uiteindelijk moet dit ook weer op laptop gaan draaien i.p.v. gewone pc (of ik moet toch nog voor een raspberry pi kiezen). Dus eventueel zou ik het kunnen installeren als daar verder geen nadelen aan zitten.

Nu nog even kijken of ook de plotjes/ png´s er ook goed gaan uitkomen.

[champquestion]

En iedereen nog bedankt voor de bijdrage en hulp aan dit topic !

[RobIII]

champquestion schreef op donderdag 3 juni 2021 @ 22:40:
En iedereen nog bedankt voor de bijdrage en hulp aan dit topic !

Heel fijn dat je nog even bedankt, maar om daar een week later nog eens je topic voor te kicken is ook weer wat veel van 't goede. Je kunt veel beter even een post markeren als 'beste antwoord'