Fichier corrompu lors d'un téléchargement.

Version imprimable

Bonjour,
Je suis confronté à un soucis aléatoire lorsque je télécharge les fichiers grib (.grb2) à la NOAA.
J'ai l'impression que de temps à autre, je tombe pile poil au moment où le fichier est mis a dispo et donc il ne le télécharge que "partiellement" ce qui plus tard me fait planter le script.

Voici le code que j'utilise (simplifié):
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 from requests import Session [...] s = Session() noaaUrl = 'https://nomads.ncep.noaa.gov/cgi-bin/filter_gfs_1p00.pl' params = { 'file': 'file', 'lev_10_m_above_ground': 'on', 'var_UGRD': 'on', 'var_VGRD': 'on', 'leftlon': '0', 'rightlon': '360', 'toplat': '90', 'bottomlat': '-90', 'dir': 'dir' } for CURR_TM in range(0, 387, 3): params['file'] = 'gfs.t' + TZ + 'z.pgrb2.1p00.f' + TM params['dir'] = '/gfs.' + YYYYMMDD + '/' + TZ grb2file = 'GFS1_' + YYYYMMDD + '_' + TZ + '_' + TM + '.grb2' while True: r = s.get(noaaUrl, params=params) if r.status_code != 200: # r.status_code != requests.codes.ok print('Waiting ...') sleep(60) else: break r = s.get(noaaUrl, params=params) with open(join(PATH_FOLDER_GRB2, grb2file), 'wb') as f: for chunk in r.iter_content(chunk_size=None): f.write(chunk) [...]
Est ce que quelque chose choc dans ce bout de code ?

J'essaye en général de me débrouiller par moi même mais là clairement je sais plus trop où chercher pour résoudre mon soucis ...

Y'a t'il un moyen de vérifier l'intégrité du fichier téléchargé ? Si oui vers quelle méthode se tourner ?

J'ai pensé à utiliser Try: ... Except "Error" : ... pour relancer le script en cas de plantage car il plante plus loin quand j'exploite le fichier corrompu, mais résoudre cette histoire " d'intégrité du fichier " me semble plus appropriée.

Merci de vos lumières 😉

26/12/2020, 17h03
wiztricks

Salut,

Il faut déjà préciser le type de la corruption: il manque des blocks, la fin du fichier,... c'est pas pareil que s'il y a des bytes inversés çà et là.

Citation:

J'ai l'impression que de temps à autre, je tombe pile poil au moment où le fichier est mis a dispo et donc il ne le télécharge que "partiellement" ce qui plus tard me fait planter le script.

Avec un peu de chance, la taille du fichier a été transmise dans l'en-tête.
Si elle est cohérente avec le nombre de bytes récupérés, c'est que le serveur a expédié le fichier dans l'état où il l'a trouvé lors de la requête. Bizarrerie à signaler au webmaster.... et en attendant, il va falloir trouver un truc permettant de tester que le fichier n'est pas en cours de création.

- W

Pour le type de la corruption j'en sais rien, le fichier n'est pas complet c'est tout ce que je vois.
En moyenne un TM avec les params que j'utilise (10m above ground, UGRID, VGRID) fait env 155 Ko, quand le fichier est corrompu il fait 455 octets.

J'ai regardé dans l'entête et voici ce qu'elle contient

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
{
    'Date': 'Sat, 26 Dec 2020 16:19:30 GMT',
    'Server': 'Apache',
    'X-Frame-Options': 'SAMEORIGIN, SAMEORIGIN',
    'X-Content-Type-Options': 'nosniff, nosniff',
    'X-XSS-Protection': '1; mode=block, 1; mode=block',
    'Content-Transfer-Encoding': 'binary',
    'Content-Disposition': 'attachment; filename="gfs.t06z.pgrb2.1p00.f006"',
    'Content-Description': 'grib2 file',
    'Content-Type': 'application/octet-stream',
    'Via': '1.1 nomads.ncep.noaa.gov-80',
    'Cache-Control': 'max-age=14400',
    'Expires': 'Sat, 26 Dec 2020 20:19:30 GMT',
    'Keep-Alive': 'timeout=300, max=100',
    'Connection': 'Keep-Alive',
    'Transfer-Encoding': 'chunked',
    'Strict-Transport-Security': 'max-age=31536000; includeSubdomains; preload',
    'Set-Cookie': 'NSC_opnbet-cmes-ttm=ffffffff09a49e4145525d5f4f58455e445a4a423660;path=/;secure;httponly'
}

26/12/2020, 17h27
VinsS
Salut,

Quelle est la taille de ces fichiers ?
Si ce sont des fichiers d'un Mo ou plus il est préférable de les télécharger en streaming.
Voir ici: https://requests.readthedocs.io/en/l...e.iter_content

Tu peux connaître la taille des fichiers avant téléchargement.
Avec urllib.request j'utilise ceci:
Code:

1 2 3 4 5 with contextlib.closing(urllib.request.urlopen(url, None, 6)) as fp: headers = fp.info() if "content-length" in headers: size = int(headers["Content-Length"])
Avec Requests ce devrait être similaire.

Donc, ensuite, tu peux comparer la taille du fichier a la valeur de "content-length" et t'assurer qu'il est bien complet.
26/12/2020, 17h31
rlelamer

il apparait pas 'Content-Length' dans l'entête justement, il me retourne donc 0.
26/12/2020, 17h45
VinsS

Je suppose que tu as les spécifications de ces fichiers puisque tu les utilises et la taille du fichier ou des données est peut-être indiquée dans l'entête, après le magic-number qui sont les premiers octets
26/12/2020, 17h55
rlelamer

Là tu m'as perdu 😖

Je suis pas un As du Python j'en comprends juste les grandes lignes quand aux gribs en eux même, j'utilise CDO (Climate Data Operators) pour les manipuler, tout ce qui sort de ce cadre est inconnu pour moi ...

Pour faire simple, je pourrais pas ajouter un " Si le fichier grb2 ne fait pas entre 150 et 160 Ko, tu me le retélécharges sinon le script continue "
C'est pas génial comme solution mais pourrais être fonctionnelle, non ?

Bien sûr que tu peux faire cela mais ici https://www.weather.gov/mdl/grib_design je vois ceci:
------------------------------------------------------------------
GRIB2 files for a given element and region will be split into two files, one containing the forecast grids for the period Day 1 through Day 3, the other containing the forecast grids for the period Day 4 through Day 7. These files are located in different directories at the NWSTG FTP download site.

Every NDFD GRIB file begins with a flag field separator of the format:
****nnnnnnnnnn****\lf

where the "nnnnnnnnnn" is the size in bytes of the file, (minus the separator), right justified with leading zeroes, and with a trailing "\lf". The "\lf" character represents a single octet with the decimal value of 10. The size of the Flag field separator is 19 bytes.
------------------------------------------------------------------

Donc tu peux essayer ceci sur tes fichiers déjà correctement téléchargés pour voir si mon code est juste:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 with open(filename, 'rb') as infile: block = list(infile.read(19)) num = [] for c in block[4:15]: if chr(c).isdigit(): num.append(chr(c)) else: raise size = int(''.join(num)) print("Size of %s: %s bytes" %(filename, size+19))

Heu je dois réfléchir avec mes pieds ... j'arrive pas a faire fonctionner le code correctement ...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
filename = '/Users/romain/Downloads/grib/gfs.t06z.pgrb2.1p00.f006'
 
with open(filename, 'rb') as infile:
    block = list(infile.read(19))
    num = []
    for c in block[4:15]:
        if chr(c).isdigit():
            num.append(chr(c))
        else:
            raise
 
    size = int(''.join(num))
    print("Size of %s: %s bytes" %(filename, size+19))

Retourne

Code:

1
2
3
4
5
6
 
$ python3 check.py 
Traceback (most recent call last):
  File "/Users/romain/Downloads/grib/check.py", line 10, in <module>
    raise
RuntimeError: No active exception to reraise

voici une URL type (valide) de la NOAA

Code:

1
2
 
https://nomads.ncep.noaa.gov/cgi-bin/filter_gfs_1p00.pl?file=gfs.t06z.pgrb2.1p00.f006&lev_10_m_above_ground=on&var_UGRD=on&var_VGRD=on&leftlon=0&rightlon=360&toplat=90&bottomlat=-90&dir=%2Fgfs.20201226%2F06

C'est une erreur dans mon code le slice doit être block[4:14]:

Tant qu'à faire je l'ai testé:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
txt = b"****0000254125****\nabracadabra" # taille réelle: 254144
with open("grib", "wb") as outf:
    outf.write(txt)
 
with open("grib", 'rb') as infile:
    block = list(infile.read(19))
    num = []
    for c in block[4:14]:
        if chr(c).isdigit():
            num.append(chr(c))
        else:
            print(c, chr(c))
            raise
 
    size = int(''.join(num))
    print("Size of %s: %s bytes" %("grib", size+19))

ça me paraît OK

26/12/2020, 18h52
rlelamer

j'arrive toujours pas à le faire fonctionner ... je vois pas ce que je loupe là ...
26/12/2020, 18h59
VinsS

Donne-moi le lien d'un fichier ou met-le en attachement.
26/12/2020, 19h02
rlelamer

Il y est plus haut mais sinon en DDL sur le site de la NOAA via ce lien

=> https://nomads.ncep.noaa.gov/cgi-bin....20201226%2F06

Merci de mon coté je continue de regarder ce qui ne va pas (ce que je ne fais pas correctement)
26/12/2020, 19h18
VinsS

Mais ça, c'est semble-t-il une archive de donnée GRIB et donc mon code ne convient plus du tout.

J'ai testé les 128 premiers octets et rien qui ne s'apparente à des nombres.

En attendant d'en savoir plus sur ce format il faudra te contenter de ta solution de rechange.

1 pièce(s) jointe(s)

J'ai trouvé l'explication de pourquoi 'Content-Length' ne se trouve pas dans le header.

Pièce jointe 587469

Donc il ne me reste pas 15 solutions pour vérifier que le fichiers soit complet si je comprends bien ( = os.path.getsize(PATH_OF_FILE) ?)

J'ai continué à lire et relire la page sur requests et j'ai modifié le code comme ceci
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 while True: r = s.get(noaaUrl, params=params, stream=False) if r.status_code != codes.ok and r.raise_for_status() != None: print('Waiting ...') sleep(60) else: break r = s.get(noaaUrl, params=params, stream=False) with open(join(path_c_tz_grb2, grb2file), 'wb') as f: for chunk in r.iter_content(chunk_size=None): f.write(chunk)
Je ne sais pas pas juger si l'ajout de stream=False et r.raise_for_status() != None apportent réellement quelque chose ...

Bonjour,

J'aime pas ne pas comprendre, alors je m'y suis replongé ... 🤯

r.status_code != codes.ok semble similaire à r.raise_for_status() != None.
Mais comme les 2 existent, je me dis qu'il doit il y avoir une différence ..., quelle est elle ?

De mon coté, je remarque que je peux obtenir un <Response [200]> mais que le fichier peut ne pas être complet au moment de ma demande (= r.status_code = codes.ok )
Lorsque r.raise_for_status() retourne None, il check autre chose ?
J'ai l'impression qu'il est plus "global" et donc quand il retourne None, c'est que TOUT est OK (c'est l'idée que j'en ai en tout cas ...)

J'ai aussi à nouveau regardé l'argument stream=None/False/True & chunk_size=None/XXXX.
J'ai compris que stream=True est systématiquement utilisé pour de gros fichiers mais je me suis "amusé" à faire quelques petits tests de "performances" sur un fichier grib (qui fait env 155 ko)

J'obtiens de meilleurs résultats avec stream=True / chunk_size=64 vs stream=False /chunk_size=None vs d'autres comparaisons, donc ça présente aussi un intérêt sur de petits fichiers ?

De tout ça j'en arrive à ce code, qui me semble plus "robuste" et plus "performant" que la version actuelle utilisée, vous me direz si je me trompe.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 from requests import Session [...] s = Session() noaaUrl = 'https://nomads.ncep.noaa.gov/cgi-bin/filter_gfs_1p00.pl' params = { 'file': 'file', 'lev_10_m_above_ground': 'on', 'var_UGRD': 'on', 'var_VGRD': 'on', 'leftlon': '0', 'rightlon': '360', 'toplat': '90', 'bottomlat': '-90', 'dir': 'dir' } for CURR_TM in range(0, 387, 3): params['file'] = 'gfs.t' + TZ + 'z.pgrb2.1p00.f' + TM params['dir'] = '/gfs.' + YYYYMMDD + '/' + TZ GRB2FILE = 'GFS1_' + YYYYMMDD + '_' + TZ + '_' + TM + '.grb2' while True: with s.get(noaaUrl, params=params, stream=True) as r: if r.raise_for_status() != None: print('Waiting ...') sleep(60) else: break with s.get(noaaUrl, params=params, stream=True) as r: with open(join(PATH_DIR_GRB2, GRB2FILE), 'wb') as f: for chunk in r.iter_content(chunk_size=64): f.write(chunk) [...]
Merci 😉

27/12/2020, 15h58
wiztricks

Salut,

Citation:

Envoyé par rlelamer

J'aime pas ne pas comprendre, alors je m'y suis replongé ... 🤯

r.status_code != codes.ok semble similaire à r.raise_for_status() != None.
Mais comme les 2 existent, je me dis qu'il doit il y avoir une différence ..., quelle est elle ?

De mon coté, je remarque que je peux obtenir un <Response [200]> mais que le fichier peut ne pas être complet au moment de ma demande (= r.status_code = codes.ok )
Lorsque r.raise_for_status() retourne None, il check autre chose ?

Lever une exception si le status n'est pas ok ou tester la condition explicitement, c'est juste 2 façons de faire la même chose. Elles peuvent être utiles suivant le code qu'on écrit mais çà ne change pas grand chose: soit c'est OK et on continue avec la suite soit çà ne l'est pas et il faut recommencer ou abandonner.

Citation:

Envoyé par rlelamer

De tout ça j'en arrive à ce code, qui me semble plus "robuste" et plus "performant" que la version actuelle utilisée, vous me direz si je me trompe.

Je n'ai pas lu les différents échanges mais soit çà détecte si la copie est complète (ou çà recommence) soit on s'en rendra compte plus tard (et on a rien changé).

- W

Merci pour les précisions @wiztricks 😉

Enfaite à force de modifier le code dans tous les sens, je crois que j'ai mis la main sur le potentiel problème qui se traduit par un plantage aléatoire du script ...

Actuellement :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
    if exists(join(PATH_NC, FILE_NC)):
        pass
    else:
        while True:
            with s.get(noaaUrl, params=params, stream=True) as r:
                if r.raise_for_status() != None:
                    print('Waiting ...')
                    sleep(60)
                else:
                    break
 
        with s.get(noaaUrl, params=params, stream=True) as r:
            with open(join(PATH_GRB2, FILE_GRB2), 'wb') as f:
                for chunk in r.iter_content(chunk_size=64):
                    f.write(chunk)
 
                    command1
 
                    command2
 
                    command3
 
    command4

La command1 comme un traitement à la volée ? j'ai l'impression que oui et forcement, si c'est le cas et que le fichier n'est pas complet, ça plante ...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
    if exists(join(PATH_NC, FILE_NC)):
        pass
    else:
        while True:
            with s.get(noaaUrl, params=params, stream=True) as r:
                if r.raise_for_status() != None:
                    print('Waiting ...')
                    sleep(60)
                else:
                    break
 
        with s.get(noaaUrl, params=params, stream=True) as r:
            with open(join(PATH_GRB2, FILE_GRB2), 'wb') as f:
                for chunk in r.iter_content(chunk_size=64):
                    f.write(chunk)
 
        command1
 
        command2
 
        command3
 
    command4

Un "vulgaire" problème d'indentation ne serait il pas l'origine de mes histoires de plantages ... 🤔

27/12/2020, 20h46
wiztricks

Salut,

Citation:

Envoyé par rlelamer

Un "vulgaire" problème d'indentation ne serait il pas l'origine de mes histoires de plantages ... 🤔

Effectivement, on peut imaginer que la fin du fichier n'a pas été écrite sur disque si on le relit avant .flush ou .close. Mais quand on ne sait pas trop, on regarde ce que çà fait et si le problème ne se reproduit plus, ben, on peut se dire que c'était une bonne piste (même si on a rien compris voire rien corrigé).

Ceci dit ce n'est pas un simple problème d'indentation. Quand on programme, on divise le travail en fonctions qui réalisent une unité logique du traitement. Çà permet de tester les bouts indépendamment les uns des autres et de les composer par la suite avec un minimum de confiance sur ce qui a été testé (ou pas).

note: si on ne s'applique pas à découper le code, on se retrouve à passer un temps non négligeable à se poser de mauvaises questions (çà fait n'importe quoi mais comme on est sûr de rien, on ne sait pas où chercher)... Ce qui est épuisant à la longue.

- W