[gamelist.xml] Séparer les données statiques et dynamiques ?

[dJ0]

Une idée que j’ai depuis un moment, et je voulais voir si d’autres personnes de la communauté la partageait :

Je ne sais pas vous, mais moi j’aime bien ces petites statistiques que l’on peut avoir sur les jeux : la dernière fois que l’on a joué à un jeu, le nombre de fois... D’ailleurs on pourrait même imaginer en rajouter d’autres (genre le nombre d’heures passés sur un jeu : Oh la vache ça fait plus de 20h que je suis sur celui là !! , en mode « steam » )
Ces stats sont encore mieux mises en valeur avec Recalbox 7 car dorénavant on a une section spéciale pour les derniers jeux joués

Toutes ces choses, ainsi que les choix des favoris, sont enregistrées dans le fichier gamelist.xml dans chaque dossier rom

Le problème ? A chaque scrap externe, toutes ces infos se font zigouillées ! La 1ère chose que fait un scrapper c’est de supprimer le gamelist.xml pour en créer un autre (mais j’ai remarqué que le scrapper interne de RecalBox 7 ne fait pas ça, on ne perd rien, bien joué les gars c’est déjà vachement mieux ) Et même sans scrap, quand on veut faire un backup incrémentiel de sa recalbox, c’est un peu le bordel dans le fichier gamelist pour s’y retrouver car tout se remet dans l’ordre du « dernier joué » , donc pratiquement impossible de comparer les données du fichier...

D’où l’idée de séparer les infos statiques et dynamiques en plusieurs fichiers.

Toutes les données récoltées par le scrapper, et qui sont donc des informations intrinsèques aux jeux, qui n’ont pas vocation à bouger en jouant, pourraient rester dans le fichier « gamelist.xml ». Ensuite, les données dynamiques (playcount, lastplayed, favorites) seraient dans un autre fichier « gamestats.xml » par exemple
De cette façon, plus de souci de perte d’infos au prochain scrap en sauvegardant simplement les fichiers « gamestats ». On pourrait reprendre exactement la même architecture XML que le fichier « gamelist » afin de faciliter la chose. Au risque de s’éparpiller, on pourrait même pousser le bouchon plus loin en créant un fichier « gamefavorites.xml » qui ne serait là que pour l’info des favoris.

Avec ce type d’architecture :

• On pourrait permettre que les favoris ne soient plus perdus en sauvegardant les fichiers « gamefavorites.xml » et même imaginer bloquer ces fichiers en lecture seule lorsqu’on veut éviter qu’une fausse manip fasse disparaitre des favoris (cas d’utilisateurs « invité » qui se trompent de bouton) Je crois avoir déjà vu des demandes dans ce sens
• On peut faire des scraps externes comme on veut sans risquer la perte d’infos
• On peut sauvegarder séparément ses stats de jeux
• On peut plus facilement faire des backups incrémentiels et vérifier les différences pour être sûr de ne pas faire d’erreurs
• Et pour les gens qui n’aiment pas ces stats (j’en ai vu sur des forums) ils pourront très facilement supprimer ces stats en effaçant simplement les fichiers « gamestats »

Qu’est-ce que vous en pensez ? Si pour la team il s’agit d’un problème de manque de temps, je peux peut-être aider pour vous faire des patchs/commit nécessaires.

[Bkg2k]

@dJ0 C'est déjà en cours d'étude

[Fab2Ris]

@dJ0 said in [gamelist.xml] Séparer les données statiques et dynamiques ?:

s vous, mais moi j’aime bien ces petites statistiques que l’on peut avoir sur les jeux : la dernière fois que l’on a joué à un jeu, le nombre de fois... D’ailleurs on pourrait même imaginer en rajouter d’autres (genre le nombre d’heures passés sur un jeu : Oh la vache ça fait plus de 20h que je suis sur celui là !! , en mode « steam » )
Ces stats sont encore mieux mises en valeur avec Recalbox 7 car dorénavant on a une section spéciale pour les derniers jeux joués
Toutes ces choses, ainsi que les choix des favoris, sont enregistrées dans le fichier gamelist.xml dans chaque dossier rom
Le problème ? A chaque scrap externe, toutes ces infos se font zigouillées ! La 1ère chose que fait un scrapper c’est de supprimer le gamelist.xml pour en créer un autre (mais j’ai remarqué que le scrapper interne de RecalBox 7 ne fait pas ça, on ne perd rien, bien joué les gars c’est déjà vachement mieux ) Et même sans scrap, quand on veu

J'adore ce genre d'idées, merci pour votre feedback !
Un coup à faire perdre le peu de cheveux qu'il reste à @Bkg2k ^^

[Bkg2k]

@Fab2Ris Haha non, ça fait des mois qu'on réfléchis à la meilleure méthode pour séparer les données "scrappables" des données "d'exploitation".
C'est juste qu'on est pas 50 à bosser sur EmulationStation

[dJ0]

Ah c'est cool, merci
Mon idée au-dessus était pour faire au plus simple (en résumer, un simple découpage du gamelist en 2 ou 3), c'est ce qui me paraissait le moins chronophage
Mais après, niveau temps de démarrage/fiabilité/etc, je sais pas si garder le XML est forcément la meilleure solution.
Et du coup, pour complexifier la chose, je me demande si des fichiers uniques "gamefavorite" et "gamestat" positionné plus haut (à la racine de "roms") ne seraient pas plus pratique pour les utilisateurs (là on pourrait faire des backups/contrôles/suppressions en touchant un seul fichier, c'est encore mieux !) mais après niveau codage ça doit être un peu plus chiant...

Ayant déjà bidouillé du linux sous buildroot, j'aurais été curieux de regarder sous le capot pour voir si c'était simple ou pas à faire tout ce bordel Les sources anciennes qu'on trouve (genre là : https://gitlab.com/recalbox/recalbox) elles sont vachement éloignées par rapport au emulationstation de Recalbox 7 ?

[acris]

Bonsoir @dJ0
tout les repository gitlab du projet sont à jour.

[dJ0]

@acris said in [gamelist.xml] Séparer les données statiques et dynamiques ?:

Bonsoir @dJ0
tout les repository gitlab du projet sont à jour.

Ok, j'avais cru que les sources étaient plus dispo (mais c'était peut-être uniquement le temps que la version finale sorte, pour le suspense ^^)

[dJ0]

Bon, j'aurais pas du regarder sous le capot, je me suis fait peur
Je comprend l'histoire d'arrachage de cheveux, vu comment sont gaulées certaines fonctions...(UpdateGamelistXml , Pa**eGamelistXml , https://gitlab.com/recalbox/recalbox-emulationstation/-/blob/master/es-app/src/systems/SystemData.cpp)
J'ai un peu présumé de mes forces, j'arrive pas à comprendre le chemin des données et leur stockage, ça a l'air très bien optimisée mais faut être le créateur pour reconstituer tout le chemin

Je vais laisser les pros et @Bkg2k sur le coup, en espérant que vous puissiez nous faire quelque chose de bien avant d'être chauve