Game statistics
-
@muldjord
That answers my question.
It seems this leaves two options for fixing the issue.- Implement the same hashing and calculation of all the id's as they are implemented in skyscraper so I can use the db.xml as a dictionary.
or - Extend skyscraper to cache rompath -> id/sha1sum in a file given an argument.
I can't see why 1 would be a useful option, that would be double work and I don't want to extend the stats tool to have scraper functionality.
2 makes a lot of sense to me. It opens up the db.xml data to be used with external tools and it would save time if you were to run skyscraper again. I imagine this wouldn't be too complicated to implement.
Is this something you would be able to implement in the near future or should I consider taking a look? - Implement the same hashing and calculation of all the id's as they are implemented in skyscraper so I can use the db.xml as a dictionary.
-
@langest said in Game statistics:
Is this something you would be able to implement in the near future or should I consider taking a look?
I'd go with option 1 in this case. I'm not currently looking for contributions and I'm eager to work on this feature myself as it's an interesting problem (the checksum lookups) with high optimization potential. But I am not able to give you an ETA.
EDIT: Just a thought: Is it not a bit much to make this rely so much on Skyscraper's db.xml (unless it's just one of several lookup methods you plan to implement)? Just my 5 cents.
-
@muldjord
Alright,
Maybe I could suggest adding the rom path to the Resource struct
https://github.com/muldjord/skyscraper/blob/225136b245c1fca4936062f1fb5430691beed283/src/cache.h#L40
You already seem to have it in the GameEntrys path member. And then together with timestamp it would be easy to see if you need to update the resource.
You probably can't save the path to sha1 mapping in the same resource nodes that the rest of the resources use, but it shouldn't be a problem to introduce a new node either in db.xml or in a separate file. -
@langest I promise it will be well thought through and backwards compatible in the sense that it will convert old entries if needed on-the-fly. If anything this has made me realize that now is probably the time to look into this.
EDIT: A file location for the rom is not very useful. If you move your files to a different directory (or a different system entirely, or someone sends you their cache), they need to still be identifiable. This has to be contained to the file itself, so modification time makes sense for this purpose.
I might also change it to always only do the checksum on the first 512 k of data instead of the entire rom. This will make it quite a lot faster to begin with. And combined with the lookup table this will prove a significat optimization. And for anyone following this, I will of course make sure this will convert "old" cache id's on the fly, so it won't break anything. -
now is probably the time to look into this
Glad to hear it. :)
checksum on the first 512 k of data instead of the entire rom
This sounds like a really good idea.
-
@muldjord said in Game statistics:
Just a thought: Is it not a bit much to make this rely so much on Skyscraper's db.xml (unless it's just one of several lookup methods you plan to implement)? Just my 5 cents.
I implemented it as separate module. You can easily replace it with something else to get the rom meta information. You just plug in a new
get_title_info(som_path: str, system: str) -> title. The reason why I depend on skyscraper is because I don't want to build a scraper, so I need to depend on at least one other scraper to get the meta info. And skyscraper is the one I am using on my system, so it makes sense for me to use it. I understand that the db.xml is not supposed to be part of an external api (in its current state) and that because of this it might seem a bit strange to depend on it.
You can use the tool without any meta information but then the title be whatever your rom name is. And at least for arcade this could be somewhat confusing. -
Why don't you use the info from the
gamelist.xmlinstead of the Skyscraper's cache ? This way it's the name that appears in ES and you don't have to hash the ROM.
Regarding arcade games ROMs, Emulationstations comes with a list of ROM name -> Game name mappings, it's in/opt/retropie/supplementary/emulationstation/resources/mamenames.xml. It uses the list to show the pretty name in gamelists for systems which are considered Arcade like. -
@mitu
Because I forgot that this file should have all the info I need.
You're absolutely right. This is the way to go. -
@langest I've been working all day to implement a "quick id" system into Skyscraper. It's functional right now, but untested. You were right about the necessity of the filepath for this system to work. I basically do a check on lastmodified and filepath. And if lastmodified is in the past or equal and filepath matches, I use the cached id from my quickid list. Otherwise it reverts to calculating the id from the file itself. More info soon as I test it a bit further. And for obvious reasons I'll move any further comments I have on this to the Skyscraper thread. :)
-
Did the implementation using gamelist.xml, was very easy and the program is lightning fast now that it doesn't do any file IO or hashing.
Not as interesting problem to solve, but it works just as expected. (Might have some minor bug)
Thanks for the input @mitu and @muldjord .
I am still looking forward to the cache improvements of skyscraper. I'll make sure to look by the skyscraper thread to see when it is finished. -
I have implemented a bash menu, similar to the ones used in the rest of RetroPie.
I am also usingdialogsince I though it would look consistent.
However, it seems like controller support doesn't work by default in the menu.
How are the controller configured to work in the retropie-setup.sh for instance? -
@langest There's a helper program (
joy2key) which translates the gamepad inputs to keyboard inputs to navigate and use thedialogscreens. Look at thejoy2keyStartandjoy2keyStopfunctions here. -
Thanks
-
@mitu
Do you think it would be possible to assume I am running on RetroPie and source the helpers into my scrip? Or do I need to copy the code? -
@langest It's up to you - however without a RetroPie installation the
joy2keyprogram might not be available to run. -
@mitu
What would make the most sense to me would be to reuse the already implemented functionality in retro pie, because I don't plan to use the dialog interface anywhere else.
The end goal of the tui is to add it to experimental programs in the retro pie install script.
I tried to source the files, but I most likely did something wrong.
I haven't really done much bash programming before so I am not sure how everything should be set up. Could you give me some pointers to get started?
ThanksOn a separate note, I have come up with some neat new features for the python program that I am going to add. Such as bar chart for visualization and weekly/daily activity.
-
@administrators Maybe this thread should have been in the ideas and development sub-forum.
-
@langest said in Game statistics:
new features for the python program that I am going to add. Such as bar chart for visualization
Got it implemented now together with a new exclude flag as well:
$ python3 /home/pi/repos/RetroStats/retro-stats/game_stats.py -c total -b 20 -n 4 -e kodi Wario Land 3 ▏ 6:36:28 ████████████████████ Crash Team Racing ▏ 2:01:08 ██████ Super Mario 64 ▏ 1:59:56 ██████ Pokémon Pinball: Ruby & Sapphire ▏ 0:55:12 ██▊ $ python3 /home/pi/repos/RetroStats/retro-stats/game_stats.py -c total -b 20 -n 3 -s nes -c times Balloon Fight ▏ 3 ████████████████████ Salamander ▏ 2 █████████████▎ Smurfs, The ▏ 1 ██████▋ -
I have implemented the daily schedule feature. It can now tell you when during a day you spend most time playing your games.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ░░░░▒▒▒▒░░░░▒▒▒▒▒▒▒▒░░░░░░░░▓▓▓▓▒▒▒▒▓▓▓▓████████░░░░Next step would be to extend the daily view to a weekly view so you can track your invested time per hour per week day. And possibly add some machine learning to categorize invested time to get a nice gradient. Right now I hardcoded some values that looked good on my data.
Of course you can use this new view with some selected systems or excluded systems.I also updated the format of the log to make sure that the time in the log is UTC. I then convert to your local time zone when printing. You either throw away your current log or use the convert script here: https://github.com/langest/RetroStats/commit/e8567b456c6e2f3d5e9bdbf6f764d9abcca3361f if you want to keep your data.
Also, if someone who reads this could give me some pointers on how to make this available in the install script experimental section or how to the controllers working in the TUI, I would be grateful, more detailed question above. Until then you will probably have to run this via CLI.
-
I extended the daily view to a weekly view and added a recent history option and a lookback option. Lookback decides how many recent days you want your stats from.
$ python3 /home/pi/repos/RetroStats/retro-stats/game_stats.py -w Monday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓ Tuesday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ▒▒▒▒▓▓▓▓▓▓▓▓ Wednesday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ▒▒▒▒████████▓▓▓▓ Thursday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ░░░░▒▒▒▒▒▒▒▒████▓▓▓▓ Friday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ░░░░░░░░▒▒▒▒▒▒▒▒░░░░░░░░▓▓▓▓████▓▓▓▓ Saturday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓████▓▓▓▓████▓▓▓▓▓▓▓▓▒▒▒▒ Sunday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▓▓▓▓ ▓▓▓▓████████▓▓▓▓████▓▓▓▓$ python3 /home/pi/repos/RetroStats/retro-stats/game_stats.py -r -n5 2019-11-01 19:36:37+00:00 gba Pokemon Gaia 2019-11-01 19:15:18+00:00 n64 Mario Kart 64 2019-11-01 18:49:16+00:00 kodi 2019-10-31 19:39:49+00:00 gba Rhythm Tengoku 2019-10-30 20:37:13+00:00 megadrive Sonic the Hedgehog 2
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.