search

kokolihapihvi / RockSniffer

RockSniffer application
MIT License
77 stars 29 forks source link

Output not updating on modified songs #11

Closed Warths closed 4 years ago

Warths commented 5 years ago

Hello !

I'm having a bug since a long time : If a song is already in RockSniffer cache and gets modified, it seems that the output of RockSniffer API or text files will display the previous "not problematic" song we played / scrolled on in the song selection.

I can confirm that this bug occurs with renamed psarc song title, not sure what are the other conditions but it happended on a LOT of songs after i remastered them all using CFSM. Changing the ID doesn't seems to trigger this bug (to be confirmed).

How i found / how to replicate the bug :

  1. Download "Arlandria - Foo Fighters" on the customsforge (or probably any other, but this one has a typo in the song title)
  2. Load Rocksmith and Rocksniffer, and play the song once (or probably just scroll to it, should be enough to have the song cached)
  3. Quit Rocksmith and Rocksniffer
  4. Change the song Title from "Alandria" to "Arlandria" using CFSM or RSToolKit
  5. Load Rocksmith and Rocksniffer and scroll to the song. Should be innacurate

It may be worth noting that even though informations will be incorrect, song timer (not song duration) and note streak will still be accurate (and maybe some other stuff more related to memory readout than cache )

I deleted my cache since, but maybe the fact that it was 1gb4 didn't help.

I hope the instructions help you to replicate the bug. It does not seems to be very consistent. Thanks for paying attention to it !

kokolihapihvi commented 4 years ago

Hey, sorry for the late response

This is by design because parsing through psarc files can be pretty cpu intensive. The songs are cached by file path and dlc id, the default cache being a sqlite database file. If you want to update a single song in the cache, you could open it up with a sqlite browser and edit or remove the song in question. Or if you want sniffer to take in the cfsm remastered version as a new song, you'd need to rename the file and change the dlc id.

Warths commented 4 years ago

Wouldn't re-parse the file each time it's being played fix the problem ? It's not a really high cost CPU wise

kokolihapihvi commented 4 years ago

It would yes, that is how the program was prior to version 0.2.0, but I decided to go for caching the whole dlc folder instead of using file handle query which proved to be unreliable under (seemingly) random conditions. If there was a more reliable way to determine which psarc file you are hovering on in game, then that might be preferable to caching everything. Although reading from cache is still faster than parsing the psarc file, but maybe it could compare file checksums or last changed dates...

The way it works currently is it caches everything and then uses the song id from in game to search the cache, it doesn't know the file path of the psarc file.

Warths commented 4 years ago

So, no fix due to design decision i guess ?

a simple, but bodgy solution to this on the long term, could be to have the option to rebuild the database from scratch on startup, following a scheduled configuration. I don't really like that kind of implementation, but it would be suited to the current data model. I guess this can be achieved with simple cron-like script.

Or cache entries could be bound to hash and path. If path is not reachable, then there's probably another corresponding entry if song is accessible in the game. If hash changed, the entry can be updated.

As i have no clue how the database is structured, and i'm not currently in position to check it, I don't know if this could work. And as you said, file handle query seemed unreliable, and this could be applicable to my last proposition .. ¯_(ツ)_/¯

kokolihapihvi commented 4 years ago

The fix for this would be to find an alternate way to get the path to the psarc file Rocksmith is accessing currently. I have seen it in memory but had no luck finding pointers to it.

kokolihapihvi commented 4 years ago

Hey, the latest release (v0.3.1) stores a hash of each dlc file in the cache, and will compare those whenever it's processing a file. This means it should update the cache with new information when it starts up, if the modified file has the same filename as the original.