Dépannage

Cette page décrit la version en développement : une partie n'est pas encore dans la v1.3.0. Cette page dans la v1.3.0 · Ce qui arrive

Reprendre la main sur une console bloquée, les problèmes courants, signaler un bug, et le mode développeur.

Console bloquée ?

PlayGuard ne voit que le contrôle parental du système sur lequel il tourne : l'emuMMC et la sysMMC ont chacune le leur (un code PIN supprimé sur l'une est toujours là sur l'autre). Lancez-le sur chacune de celles à corriger.

Console d'occasion

Vous connaissez le code PIN, mais l'application mobile de l'ancien propriétaire est toujours associée (la dissociation échoue, ou la réinitialisation demande son compte).

Sécurité › Dissocier l'application mobile, puis, si vous ne voulez plus du tout de contrôle parental, Supprimer tout le contrôle parental. Les deux fonctionnent hors ligne, en emuMMC comme en sysMMC.

Code PIN oublié

Afficher le code PIN demande lui-même le code PIN : il ne peut pas aider ici. Avec le module système de récupération installé (ci-dessous), déposez un fichier RESCUE et redémarrez : l'écran de récupération en définit alors un nouveau (il n'affiche jamais l'ancien). Sans lui, Supprimer tout le contrôle parental permet de repartir de zéro (une sauvegarde des réglages est d'abord enregistrée ; elle ne contient jamais le code PIN) : avec Protéger PlayGuard par le code PIN actif (par défaut, Avant une modification), mettez d'abord la carte SD dans un ordinateur et passez "pin_lock" à "off" dans sd:/config/playguard/config.json.

Le minuteur bloque tout (limite à 0 min) et le code PIN est oublié

PlayGuard lui-même ne peut pas démarrer. Installez à l'avance le module système de récupération optionnel (Console › Modules facultatifs, ou playguard-rescue.zip à la main) ; une fois bloqué, déposez un fichier vide config/playguard/RESCUE sur la carte SD et démarrez — il déverrouille la console pour que PlayGuard puisse s'ouvrir. Voir sysmodule/rescue/README.md (en anglais).

Le module doit suivre la version de PlayGuard : à chaque mise à jour de PlayGuard, extrayez à nouveau le playguard-rescue.zip de cette version (ou Mettre à jour sur l'entrée Le sysmodule de récupération n'est pas à jour de la cloche), puis redémarrez la console. Un module plus ancien laisse un rapport que PlayGuard ne peut pas vérifier : l'écran de récupération ne propose alors rien, dit que le module est plus ancien, et refaire RESCUE donne le même résultat tant qu'il n'est pas mis à jour.

Menu homebrew verrouillé

Console › Forwarders › Verrouiller le menu homebrew empêche l'album et un jeu lancé avec R d'ouvrir le menu homebrew. Si le forwarder de PlayGuard et le menu protégé ont tous deux disparu (supprimés dans les Paramètres, ou sur l'autre système : le verrou est sur la carte SD, lu par sysMMC comme par emuMMC) :

• Depuis un ordinateur : supprimez atmosphere/config/override_config.ini sur la carte SD (ou remettez config/playguard/override_config.ini.backup, le fichier d'origine), puis redémarrez la console.
• Avec le sysmodule de récupération installé (facultatif) : déposez un fichier vide config/playguard/RESCUE sur la carte SD et redémarrez ; le sysmodule lève le verrou au démarrage, et PlayGuard le signale à l'ouverture suivante. Une mise à jour d'Atmosphère depuis le verrouillage le lève de la même façon.

Console non modifiée

PlayGuard ne peut rien faire : il nécessite Atmosphère. La procédure officielle passe par la clé maîtresse du service client de Nintendo.

Problèmes courants

Le temps restant ne baisse pas

Aujourd'hui indique La console ne décompte pas le temps de jeu en ce moment quand il n'a pas bougé pendant environ 90 s. Les causes probables :

• L'horloge réseau n'a jamais été réglée. Console › Horloge réseau › Mesurer l'écart, puis réglez-la (horloge réseau).
• L'horloge a été reculée. Après un retour en arrière, le décompte s'arrête jusqu'à ce que l'horloge dépasse l'ancienne heure ; rien à faire.
• Une limite vient d'être écrite. Lancez un jeu une minute, puis vérifiez de nouveau.
• Le contrôle parental est déverrouillé temporairement. Le temps de jeu n'est peut-être pas décompté pendant ce temps : Aujourd'hui › Réactiver (ou un appui sur la pastille de l'en-tête).

Mes limites ont changé toutes seules

• L'application mobile est encore associée. Sa prochaine synchronisation écrase ce que PlayGuard a réglé : Sécurité › Dissocier l'application mobile.
• Un autre outil, ou un profil. Aujourd'hui affiche une carte orange pour des limites différentes de celles que PlayGuard a vues en dernier, et Historique › Historique des modifications liste chaque modification vue en dehors de PlayGuard. Ⓐ sur l'une remet la valeur précédente.
• Un profil programmé appliqué, ou les limites qu'il avait remplacées remises une fois sa période finie (Temps de jeu › Profils › Profil programmé).

L'enfant a joué au-delà de la limite

• La console se contente de prévenir. Temps de jeu › Quand le temps est écoulé : choisissez Suspendre le logiciel.
• Le contrôle parental est resté déverrouillé. Tant qu'il l'est, la limite du jour est en pause : la pastille de l'en-tête le dit sur chaque onglet, et un appui dessus mène à Aujourd'hui › Réactiver. Un redémarrage de la console le reverrouille aussi.
• L'horloge a été reculée. Le décompte s'arrête jusqu'à ce que l'horloge dépasse l'ancienne heure (ce qui compte).
• L'autre système. L'emuMMC et la sysMMC ont chacune leur propre contrôle parental : réglez-le sur les deux, ou masquez le menu de démarrage d'hekate (compatibilité).

Toute la limite est de nouveau disponible aujourd'hui

Changer l'horloge (l'horloge réseau ou celle de la console) remet à zéro le temps de jeu du jour. Réglez l'horloge avant que l'enfant ne joue, pas après.

PlayGuard s'ouvre en lecture seule

La console fait tourner un firmware plus récent que le plus récent testé : PlayGuard vérifie si une version plus récente le prend en charge et propose de mettre à jour (firmware plus récent). Un crayon barré à droite du titre indique que l'application est en lecture seule ; le toucher ouvre l'écran du firmware.

PlayGuard demande le code PIN tout le temps, ou jamais

Sécurité › Protéger PlayGuard par le code PIN : Avant une modification (par défaut) le demande une fois, avant la première modification, et le code vaut jusqu'à la fermeture de PlayGuard. Redemander le code PIN après 5 minutes le redemande après ce délai. Afficher le code PIN le demande toujours.

Un jeu ne démarre pas, ou affiche un « ! » sur le menu HOME

Console › Jeux installés dit ce qui ne va pas pour chacun et quoi faire ; les sauvegardes restent toujours (jeux installés).

Un forwarder protégé affiche l'erreur 2347-0100

Sa porte (config/playguard/gate-….nro) n'est plus le fichier avec lequel le forwarder a été fait : elle a été modifiée ou remplacée sur la carte SD, et le forwarder ne la lance pas. Ouvrez PlayGuard depuis son propre forwarder : il réécrit la porte au démarrage ; Console › Forwarders › Tout réinstaller refait chaque forwarder avec elle.

Un forwarder protégé se ferme aussitôt (« une erreur est survenue »)

Avant tout écran de PlayGuard, sans code d'erreur (le rapport d'Atmosphère dans atmosphere/crash_reports/ nomme le module forwarder, résultat 2000-0000) : il a été fait par un PlayGuard dont la porte était construite sans ses ressources, que le chargeur du forwarder refusait. Mettez PlayGuard à jour, puis refaites-le : la cloche et Console › Forwarders le proposent pour chaque forwarder fait avec un ancien chargeur.

Un forwarder protégé reste sur l'écran de sa porte après le PIN

Le PIN accepté, l'écran avec l'icône du homebrew reste et plus rien ne se passe : sa porte dessinait cet écran avec un seul tampon, et attendait sans fin de pouvoir dessiner le suivant. Mettez PlayGuard à jour, puis refaites-le : la cloche et Console › Forwarders le proposent pour chaque forwarder fait avec une ancienne porte.

Un forwarder affiche « Le logiciel n'a pas pu être démarré »

La console a refusé de le lancer : une vérification de signature est toujours en place. Dans l'ordre :

• Des fichiers sigpatches à côté de sys-patch. Des fichiers .ips dans atmosphere/kip_patches/fs_patches, loader_patches ou atmosphere/exefs_patches/es_patches alors que sys-patch tourne : deux outils patchent les mêmes vérifications, la cause que les fils sys-patch et sigpatches de GBAtemp citent le plus. Console › Patchs de jeux le signale, et Ⓐ y met ces fichiers de côté (déplacés dans config/playguard/sigpatches-aside/, jamais supprimés ; le bootloader/patches.ini de hekate reste). Redémarrez la console.
• Un motif que sys-patch n'a pas appliqué. Les forwarders ont besoin de ses patchs fs et loader, de chaque motif qu'il prévoit pour ce firmware (noncasigchk_17.0.0+, nocntchk_19.0.0+, noacidsigchk_10.0.0+), pas seulement d'un par module. À propos › Aide et diagnostic › Exporter un rapport de diagnostic indique, sur sa ligne game patches, la version de sys-patch et chaque motif non appliqué ; sd:/config/sys-patch/log.ini contient la même chose. Vérifiez que config/sys-patch/config.ini patche ce système (patch_emummc=1 sur emuMMC) et n'en désactive aucun ; selon le mainteneur de sys-patch, la 23.0.x ne demande pas de version plus récente que la 1.6.2.3.
• Pas de redémarrage depuis le changement de patchs. sys-patch patche au démarrage.
• Un forwarder fait par un PlayGuard plus ancien. La cloche et Console › Forwarders proposent de refaire ceux construits avec un ancien chargeur.

La cloche ou un onglet affiche une pastille orange

Quelque chose demande votre attention : Ⓨ ouvre la liste, et Ⓐ sur une entrée fait la correction ou ouvre l'endroit où elle se fait (notifications).

Signaler un bug

Une erreur affiche le code du système (par exemple 0x0001088E) avec ce que l'on en sait : quoi faire pour les codes dont le sens est documenté, sinon un rapport aide.

1. À propos › Aide et diagnostic › Exporter un rapport de diagnostic enregistre un fichier texte dans sd:/config/playguard/logs/reports/ : firmware, version d'Atmosphère, durée du démarrage et des écrans les plus lents (l'historique des changements, Tous les jeux, la vérification des jeux installés, les onglets qui se rafraîchissent seuls), horloges, stockage, masquage du numéro de série, état des patchs de jeux, ce que la redirection DNS d'Atmosphère fait des serveurs de contrôle parental et d'heure de Nintendo (lu dans son fichier hosts sur la carte SD, pas un test réseau, avec la fin du journal d'Atmosphère lui-même, atmosphere/logs/dns_mitm_startup.log), le résultat brut de chaque requête au contrôle parental, et les journaux : comment la dernière session s'est terminée, la mémoire et la place libre sur la carte SD, les derniers fichiers de plantage et les 80 dernières lignes journalisées. Il ne contient jamais le code PIN ni le numéro de série.
2. Ouvrez un ticket (en anglais ou en français) et joignez-le.

Envoyer un rapport en ligne

Console connectée, À propos › Aide et diagnostic › Envoyer un rapport… (Ⓧ sur le rapport de diagnostic en mode développeur) l'envoie dans un gist secret de votre compte GitHub, après avoir indiqué exactement ce qui part. Un rapport enregistré plus tôt dans logs/reports/ peut être envoyé de la même façon.

• Ce qui part : le rapport et chaque fichier dans un fichier à part :
• les derniers rapports de crash : les 3 derniers de PlayGuard dans logs/crashes/, et les 2 derniers d'Atmosphère d'un homebrew de la semaine passée, dans sd:/atmosphere/crash_reports/ (le crash d'un autre homebrew peut en faire partie : la liste affichée avant l'envoi dit lesquels) ;
• les journaux de cette session et de la précédente (logs/sessions/ ; un long : son début et ses 64 derniers Kio) ;
• les fichiers de débogage : la référence du bloc du minuteur, la fin de l'enregistrement du minuteur tant qu'Enregistrer le temps de jeu est activé, les 20 dernières modifications de l'historique (sans noms de jeux, de comptes ou de profils, et avec leur date seulement), et les réglages de PlayGuard.
• La connexion : déconnecté, PlayGuard propose d'abord de se connecter ; Compte GitHub, juste en dessous une fois connecté, permet de se déconnecter ; si GitHub refuse le gist, PlayGuard propose de se reconnecter.
• Ensuite : PlayGuard affiche deux QR codes, le lien sous le premier, son identifiant par groupes de quatre pour le dicter ou le recopier : le rapport, pour la personne qui vous aide déjà, et le formulaire de signalement de bug avec le lien, vos versions, la façon dont PlayGuard a été lancé (par-dessus un jeu, par son icône du menu HOME ou depuis l'Album ; ajoutez le menu) et le système (sysMMC ou emuMMC) déjà remplis, à scanner pour signaler un bug. Le lien reste aussi dans les notifications, et chacun est conservé dans logs/uploads/ sous forme de raccourci Internet (.url) qu'un ordinateur ouvre dans son navigateur.

Ce que PlayGuard garde sur la carte SD

Tout est dans sd:/config/playguard/logs/, en texte brut qu'un ordinateur ouvre :

• sessions/session_<date>.txt — un fichier par session : tout ce que PlayGuard a journalisé (ce qui n'arrivait jusqu'ici qu'à un PC par nxlink), chaque ligne avec son heure et son niveau (E erreur, W avertissement, I information), et une dernière ligne qui dit comment la session s'est terminée : === end: clean exit === (sortie normale), ou === end: crash, see logs/crashes/… === (plantage). Un fichier s'arrête de grossir à 1 Mio.
• crashes/crash_<date>.txt — un fichier par plantage, dont la première ligne dit ce qui s'est passé :
• une exception du processeur (un mauvais pointeur, une instruction inconnue, un dépassement de pile) : le type de faute et l'adresse touchée, la pile d'appels et les registres. Les adresses sont des décalages dans playguard.nro (playguard+0x1a2b3c) : la carte d'édition de liens de la version (l'artefact -linker-map de son build CI) donne la fonction. PlayGuard se termine ensuite comme avant : l'écran d'erreur de la console, et le rapport d'Atmosphère dans sd:/atmosphere/crash_reports/ ;
• une exception non rattrapée : son type et son message, et la pile d'appels ;
• une session qui ne s'est pas terminée : constatée au démarrage suivant, quand le fichier de la session précédente n'a pas de ligne de fin (un plantage que PlayGuard n'a pas pu attraper, une fermeture depuis le menu HOME pendant un blocage, ou la console éteinte), avec ses 60 dernières lignes.

Les fichiers de plantage écrits pendant que PlayGuard tourne se terminent par les 80 dernières lignes journalisées avant le plantage. - reports/, uploads/, play_timer/ — les rapports enregistrés, les liens des rapports envoyés en ligne, l'enregistrement du temps de jeu.

À propos › Aide et diagnostic règle combien de rapports, de fichiers de plantage, de journaux de session et de liens sont gardés (chaque dossier de son côté ; le plus récent reste toujours).

Mode développeur (examiner un nouveau firmware)

Appuyez sept fois sur Ⓨ sur À propos › Version ; les outils développeur apparaissent à la fin de À propos › Aide et diagnostic. Il ajoute :

• un interrupteur lecture seule — activé, l'application ne peut rien modifier : c'est la façon sûre d'examiner un nouveau firmware (l'écran firmware le propose directement) ;
• le rapport de diagnostic à l'écran (Ⓨ l'enregistre, Ⓧ l'envoie en ligne), et un raccourci pour l'exporter depuis l'onglet Temps de jeu ;
• Auto-test de la console : ce que PlayGuard vérifie seul sur cette console avant de dérouler la liste de vérification sur console à la main — le code PIN, les patchs de signature, le dossier de données, chaque forwarder fait par PlayGuard (sur le menu HOME, protégé, vu fonctionner à travers sa porte), la porte sur la carte SD, ce qu'Atmosphère lit du verrou du menu homebrew, les chemins de retour, le sysmodule de récupération. Il ne change rien, et écrit son résultat en Markdown dans config/playguard/self-test.md, à coller dans la pull request ;
• Installer un autre build sur place, pour tester un correctif avant sa publication (ci-dessous) ;
• Comparer le bloc du temps de jeu (seulement tant que l'application mobile est associée et peut se synchroniser — pas avec un fichier hosts qui bloque Nintendo ; aussi dans Sécurité), pour décoder les réglages que PlayGuard n'affiche pas encore : enregistrez le bloc brut comme référence, changez un réglage dans l'application mobile, revenez — PlayGuard liste les valeurs qui ont changé (enregistrées dans logs/reports/ sur demande). Des heures du coucher différentes selon les jours, réglées depuis l'application mobile, pourraient être confirmées ainsi. Joignez ce fichier à un ticket, ou envoyez-le avec le rapport (Envoyer un rapport…).
• Enregistrer le temps de jeu : toutes les 30 s tant que PlayGuard est ouvert, une ligne de ce que rapporte le minuteur (temps restant, temps écoulé, bloc brut des réglages…) dans logs/play_timer/log.csv, un fichier qui s'ouvre dans un tableur, plus une ligne juste après chaque modification faite par PlayGuard, qui dit laquelle (la dernière colonne, event), et une note quand l'horloge a bougé plus que le temps écoulé. Laissé ouvert après minuit, ou jusqu'à la fin du temps, il montre ce qu'un seul rapport ne peut pas montrer : quand le temps écoulé repart à zéro, ce que dit la console vers la fin. L'interrupteur est mémorisé ; il n'enregistre qu'en mode développeur. Ce qu'on sait déjà est dans parental-controls.md (en anglais).
• Vider le cache et Supprimer les fichiers journaux, chacun après une confirmation qui indique combien de fichiers et quelle place : le cache (cache/ et le nand/<système>/cache/ de chaque système : noms et icônes des jeux, derniers chiffres de l'Activité, liste des builds) est relu sur la console au besoin ; les fichiers journaux sont les fichiers de plantage, les journaux de session (sauf celui de la session en cours, encore en écriture), les rapports enregistrés et l'enregistrement du temps de jeu, tandis que uploads/ (les liens de suppression des rapports envoyés en ligne) et la référence du bloc restent. Les réglages, l'historique, les sauvegardes, les profils et les exports ne sont jamais touchés.
• Rejouer les migrations : les déplacements des anciennes organisations — le dossier de données à côté du .nro, les journaux d'avant leurs sous-dossiers, ce que tous les systèmes partageaient — chacun sur une ligne à cocher ou décocher (toutes cochées au départ ; A en bascule une), puis Rejouer les N choisies et une confirmation qui les liste avec ce que chacune déplace. Elles sont rejouées tout de suite, quoi qu'indique migrations.json (chacune ne tourne sinon qu'une fois, au premier lancement d'une version qui en a besoin ; le niveau enregistré n'est jamais abaissé) ; un fichier déjà en place n'est jamais remplacé. Une fenêtre indique combien d'éléments ont été déplacés ; chaque étape est dans le journal de session.
• Statistiques d'image : une ligne par seconde dans logs/frame_stats.txt, le temps mis à dessiner l'écran et les images en retard, pour comparer un écran à un autre sur la console. Halo d'arrière-plan éteint la lumière douce derrière les écrans (le mode de la ligne finit alors par -noglow), pour mesurer ce qu'elle coûte.

Installer un autre build

Installer un autre build met un build à la place du .nro de PlayGuard, pour tester un correctif avant sa publication.

Ce qu'il liste, chaque catégorie dans un onglet à part (Ⓛ / Ⓡ, affichés de part et d'autre des onglets, passent de l'un à l'autre ; l'écran s'ouvre sur celui du build installé, et chaque onglet a, après son nom, une étincelle et le nombre de builds plus récents que celui installé) :

• l'une des 20 dernières versions publiées (préversions comprises, étiquetées) ;
• l'un des 20 derniers commits de main ;
• le dernier build d'une pull request ouverte depuis une branche de ce dépôt (jamais depuis un fork : son code n'a pas encore été relu). A sur l'onglet des pull requests, quand il est affiché, les trie dans l'autre ordre (build le plus récent d'abord, ou par numéro) : l'aide de A dit lequel.

Chaque build affiche son titre (le sujet du commit ou de la pull request ; le message complet d'un commit sert de description) au-dessus d'étiquettes : le type de changement (Nouveauté, Correctif, Docs…) et sa portée, Rupture, la pull request d'origine d'un commit, l'état de la CI (CI OK, CI en échec, CI en cours), préversion, une coche pour le build installé ou une étincelle pour un plus récent ; son ancienneté (en minutes, en heures, puis en jours) et son commit à droite. Un build ouvre d'abord sa page : des étiquettes (son type, ses vérifications, la coche ou l'étincelle), une fiche (compilation, taille, commit, empreinte, date de suppression par GitHub), Installer, Voir sur GitHub (sa page en QR code, pour un téléphone), un avertissement quand ses vérifications sont encore en cours, puis les notes d'une version publiée ou la description d'une pull request, mises en forme depuis le Markdown de GitHub (titres, listes, cases à cocher, code, citations et encadrés, tableaux).

Sans risque à lire : tout ce qui vient de GitHub est affiché comme du simple texte : aucun lien n'est ouvert, aucun HTML ni script n'est exécuté, et les caractères invisibles qui pourraient maquiller un titre (inversion de sens, caractères de largeur nulle, de contrôle, UTF-8 invalide) sont retirés.

La connexion. Les versions publiées ne demandent rien ; les autres sont les artefacts du workflow de build, que GitHub ne donne qu'aux utilisateurs connectés. Compte GitHub connecte PlayGuard avec un code et un QR code à scanner avec un téléphone. Seules autorisations demandées : lire les fichiers du workflow de build (Actions) et créer des gists, pour Envoyer un rapport… ; sinon le jeton ne peut lire que ce qui est public. Il est gardé dans github_token, jamais envoyé avec un rapport, et Compte GitHub permet de se déconnecter. Une fois connecté, Ⓨ (Rechercher) prend le numéro d'une pull request (ouverte ou fermée) ou un commit (7 à 40 chiffres hexadécimaux) et trouve son build, uniquement depuis une branche de ce dépôt.

L'installation : PlayGuard télécharge le build, le vérifie (taille, empreinte SHA-256 enregistrée par GitHub, en-tête NRO), le met à la place de son propre .nro et redémarre dessus (le code PIN est d'abord demandé dès qu'il y en a un). Sa fenêtre dit à quelle étape il en est, la taille et la vitesse du téléchargement, et quel build il remplace ; Annuler disparaît une fois le build en cours de mise en place.

• La liste est gardée 10 minutes et s'affiche aussitôt, avec son ancienneté (Ⓧ la recharge, et l'écran aussi toutes les 3 minutes tant que les vérifications d'un build sont en cours) ; pendant son chargement, une barre à droite de l'en-tête montre où il en est. Ce que fait l'installation est dit au pied de l'écran.
• Un téléchargement interrompu (réseau perdu) reprend là où il s'est arrêté la prochaine fois que le même build est installé.
• Les artefacts expirent au bout de 90 jours.

Revenir en arrière. Le build remplacé est gardé (playguard.nro.previous) : Revenir au build précédent, dans la même liste, les échange à nouveau, après le code PIN ; il désigne ce build par sa version, sa pull request et son commit. Si un build installé d'ici (ou par Mettre à jour sur place) plante avant son premier écran, le lancement suivant de PlayGuard propose de revenir au build précédent sur un simple écran texte, avant de charger quoi que ce soit (A revient en arrière, B le lance quand même). Revenir en arrière demande le code PIN sur l'écran du code PIN de la console quand il y en a un (pas l'écran de verrouillage de PlayGuard, qui peut être ce qui plante) ; sans lui, le build installé se lance. La même liste permet de revenir à n'importe quelle version publiée à tout moment.

Quel build tourne : À propos › Version affiche le commit en mode développeur. L'en-tête de chaque écran affiche la version en cours à côté du titre : celle d'une version publiée dans une étiquette grise (1.2.0), celle de tout autre build dans une étiquette orange suivie de son commit, pour ne jamais confondre un build de test avec la version publiée.

Voir sur GitHub