Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

Versatile C++ game scraper: Skyscraper


  • Global Moderator

    @muldjord said in Versatile C++ game scraper: Skyscraper:

    I'm pretty sure it's not enabled by default unless @mitu changed that. It shouldn't be.

    Yes, it's not enabled by default - when the configuration is first generated, the refresh is disabled - https://github.com/RetroPie/RetroPie-Setup/blob/922149b09dfab04408e133114bcb2a97cf7ed87c/scriptmodules/supplementary/skyscraper.sh#L358.



  • @Clyde Yes, caching the data is extremely important for any scraper if you ask me. :) Have fun with it!

    @dudumaroja, see mitu's answer above. :)



  • Skyscraper 3.3.0 released: https://github.com/muldjord/skyscraper

    • MAJOR: File identification now uses new quick id method for up to 75% faster processing (Thank you to 'langest' for finally making me look into this)
    • Added 'pc98' platform (Thank you to 'leosmeira' for suggesting it)
    • Added 'pokemini' platform (Thank you to 'leosmeira' for suggesting it)
    • Renamed all 'sha1' file id's to 'id' as sha1 was misleading
    • Changed relevant defines to constexpr
    • ScreenScraper now always prioritizes the 'video-normalized' above 'video' (Thank you to 'JuanVCS' for suggesting this)
    • Fixed bug in ScreenScraper retry code which made it retry more than necessary

    Most prominent feature is the new quick id concept. So far Skyscraper has calculated the internal cache id's from the data of the roms every time you run Skyscraper. This seemed like a lot of work for files that rarely change, and takes a long time to do, especially for the larger roms such as n64 roms. So, I've made a new system called quick id which is basically an id caching that works seemlessly with the cache id system. Here's how it works:

    • Whenever a file processed for anything using the cache id, the cache id is calculated using the "slow" method. And at this time, the file path and file modified time is also saved in a quick id xml file. Then, the next time this particular file needs processing, it will first compare the file path and modified time from the quick id list to the actual file. If the file is still located at the same place and hasn't been modified since last run, it will look up the cache id from the quick id list.

    So everything will be "as slow as usual" the first time you process any file, since it is then forced to use the "slow" id technique as it doesn't yet know the id. But for any subsequent processing of that particular file, you will see up to a 75% improvement in speed (the larger the roms, the speedier it will be). A great platform to test it on is the n64 platform. But remember, after updating, you won't see the speed improvement until you've processed the files one way or another once so the id's get cached in the quick id list.

    A great way to test this is to update to 3.3.0, then regenerate the gamelist for any platform with Skyscraper -p <PLATFORM> and take note of how long it took . When that's done do it again and take note of the time again. It should have taken significantly shorter time the second time you ran it, as it was now able to use the quick id feature.
    The quick id list can be vacuumed together with the cache with the --cache vacuum option to avoid having lingering quick id's if you move files around or rename them.

    A lot of code has changed in this version. I've fixed some silly bugs in the ScreenScraper module aswell which made it retry more times than necessary. If you encounter any problems with any of the above, please let me know. As always I've been testing this quite a bit on my own systems, but it's impossible for me to test any use case.



  • @muldjord said in Versatile C++ game scraper: Skyscraper:

    • ScreenScraper now always prioritizes the 'video-normalized' above 'video'

    If I wanted to purge all videos from the cache to re-scrape their normalized versions, would this be the right command? (run from whichever location of the Skyscraper executable)

    Skyscraper -p PLATFORM --cache purge:video
    


  • @Clyde Almost. You need to run Skyscraper -p PLATFORM --cache purge:t=video,m=screenscraper to purge all videos from ScreenScraper. But you can just rescrape it with --refresh. Then it will overwrite the old videos automatically.



  • @muldjord Thank you. But wouldn't --refresh re-scrape all resources instead of only the videos? Although the videos are the biggest resource, I would like to avoid re-scraping every other resource as well.



  • @Clyde Long story short, that's not how it works. It always downloads "everything or nothing" due to my current implementation of the cache and how the online databases work.



  • @muldjord That's what I feared after reading the docs, thanks again. One last question (I hope): If I purge the videos only, then only they would be re-scraped in a normal scraping run without --refresh, right?

    If so, I'd rather use that, since I would very much like to have the normalized videos, but with as little stress to the SS servers as possible. I'm already donating 5โ‚ฌ/month to them, but I don't see that as a free ticket to do whatever I like. ๐Ÿ˜‡

    If it ever happens that you don't know what else to do on Skyscraper, more control over refreshing the cache would be nice (if the online servers allow it). ๐Ÿ˜Š



  • @Clyde said in Versatile C++ game scraper: Skyscraper:

    @muldjord That's what I feared after reading the docs, thanks again. One last question (I hope): If I purge the videos only, then only they would be re-scraped in a normal scraping run without --refresh, right?

    No. ;) Then it will just fetch the game from the cache without the video. Entries are only ever redownloaded from the online sources if --refresh is set. Otherwise it fetches what it has from the cache.

    If it ever happens that you don't know what else to do on Skyscraper, more control over refreshing the cache would be nice (if the online servers allow it). ๐Ÿ˜Š

    I am painfully aware :D But it's not a small change as my current implementation doesn't support this. I have ideas for it, and it might happen at some point, but don't hold your breath for it. :) Maybe for 4.0.0 at some point down the line.



  • Thanks a final time in this matter. I'll register this as one of the many things we'll have to live with in an imperfect world, then. :)



  • Skyscraper 3.3.1 released: https://github.com/muldjord/skyscraper

    • Added new '--cache edit:new=<TYPE>' option for efficient batch adding of a resource of a certain type
    • Improved ctrl+c handling
    • Protected cache write calls from ctrl+c obstruction

    If you've created reports with missing textual resources for certain types, it is now easy to add those resource using the Skyscraper -p <PLATFORM> --cache edit:new=<TYPE> --fromfile <REPORTFILE>. This will only edit the roms from the report, and move directly through each of them asking for that particular resource type to be added. Much easier and faster than before.



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.