Dépannage

Reprendre la main sur une console bloquée, signaler un bug, et le mode développeur. Retour au README.

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).

Code PIN › 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 (playguard-rescue.zip) ; 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/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.

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.

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.

À 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, 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.
Ouvrez un ticket (en anglais ou en français) et joignez-le.

Ou, console connectée, À propos › Aide et diagnostic › Envoyer un rapport en ligne (Ⓧ sur le rapport de diagnostic en mode développeur) l'envoie, avec 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) et 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), dans un gist secret de votre compte GitHub (le rapport et chaque fichier dans un fichier à part ; 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 à cette connexion, PlayGuard propose de se reconnecter), après avoir indiqué exactement ce qui part. PlayGuard affiche le lien et deux QR codes : le rapport, et le formulaire de signalement de bug avec le lien, vos versions, la façon dont PlayGuard a été lancé (par-dessus un jeu ou depuis l'Album ; ajoutez le menu) et le système (sysMMC ou emuMMC) déjà remplis. Toute personne qui a le lien peut lire le rapport, jusqu'à ce que vous supprimiez le gist sur GitHub, et un signalement de bug ouvert avec lui est public : la confirmation le dit. Chaque lien est conservé dans logs/uploads/ sous forme de raccourci Internet (.url) qu'un ordinateur ouvre dans son navigateur. Un rapport enregistré plus tôt dans logs/reports/ peut être envoyé de la même façon.

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 ;
Installer un autre build sur place, pour tester un correctif avant sa publication : l'une des 20 dernières versions publiées (préversions comprises, étiquetées), l'un des 20 derniers commits de main, ou 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), 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 compte les builds plus récents que celui installé). 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, installé ou nouveau ; son ancienneté et son commit à droite. 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). Un build ouvre d'abord sa page : des étiquettes (son type, ses vérifications, installé ou nouveau), 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), 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). 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. 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. 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 en ligne ; 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). 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). La liste est gardée 10 minutes et s'affiche aussitôt, avec son ancienneté (Ⓧ la recharge) ; pendant son chargement, une barre montre où il en est. 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é. Le build remplacé est gardé (playguard.nro.previous) : Revenir au build précédent, dans la même liste, les échange à nouveau. 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), sans le code PIN, car l'écran du code PIN peut lui-même être ce qui plante. Le reste du temps, Revenir au build précédent (ci-dessus) le fait, après le code PIN. La même liste permet de revenir à n'importe quelle version publiée à tout moment ; À 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. Les artefacts expirent au bout de 90 jours ;
Comparer le bloc du temps de jeu (aussi dans Code PIN tant que l'application mobile est associée), 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 en ligne).
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.

Voir sur GitHub