Rework handling of Title Updates (make it faster)

[lprot 0]

Currently (as of v0.6) Aurora on first start scans Content and Cache folder for TU, fills the database and copies TUs it found to Aurora folder.

When you set TU you like, it deletes TU in Content/Cache folder on Hdd and copies TU from Aurora folder to Hdd. 

If you download TU from Aurora it puts it in Aurora folder and if you activate it Aurora deletes TU from Content/Cache and copies from Aurora folder to Hdd.

All of that is time and space consuming as Aurora makes a copy of all TUs (imagine if you got 10Gbytes of TU files) to it's own folder.

 

Instead of all that complications Aurora could do:

1. Don't use it's own Title Updates folder at all and don't scan Content/Cache folders on start.

2. If user goes to Title Updates options of the Title in Aurora GUI, only at this time Aurora could scan corresponding Content/TitleID/000B0000 folder and /Cache folder for that TitleID and show the list of TUs for that title. Naming of the files in Content and Cache folder in it's original locations on Hdd should be like that:

tu00000009_00000000 - for the currently active TU let's say ver 27

01_tu00000009_00000000 - for TU1

02_tu00000009_00000000 - for TU2

xx_tu00000009_00000000 - for TUxx

If user activates TU2, tu00000009_00000000 gets renamed to 27_tu00000009_00000000 and 02_tu00000009_00000000 to tu00000009_00000000.

If user downloads TU from xboxunity it downloads directly to Content/Cache folder and correspondingly gets renamed.

For Cache folder:

TU_XXXXX_XXXXXX for activated TU

xx_TU_XXXXX_XXXXXX for other TUxx

 

Hope I'm clear

[gavin_darkglider 1562]

You do realize that FSD handles TU's the same way. lol. You can also disable TU scanning in aurora, and erase the cached files. Problem is, once you launch the game it will erase the TU, as it is not going to think you want it enabled. Chances are we are not going to change how this works. it is done this way for a reason. If they are cached with aurora, it is easier for aurora to handle them from a coding standpoint, in both the DB, and otherwise. Also, if you have more than one TU in the tu folder, but rename it, it could cause issues with the game if it is poorly coded, and tries to load all of them. That being said, if you dont like the way we do it, then dont use the software. We dont force anyone to use our dashboard, it is optional. I would be happy to see you write your own, that comes with as many features as Aurora, and runs as smoothly. Hell, I would even be happy to help with bug fixes, and testing. Chances are, you dont know the first thing about programming, let alone doing it for the PPC64 arch, let alone being locked into the XDK API(You could get around this by coding in ASM, I guess, but good luck there!), but want to complain about how we work around these issues. This might seem a bit harsh, but considering this method has worked for people for years, and is the most guaranteed way to keep things stable for all games, this (probably) will not ever change.  I am betting you that I have more TU's than you do in my 600+ game library, considering I have multiple TU's for every game, and you dont hear me complaining about space issues. Here is an idea, get a bigger HDD. Problem solved.

[lprot 0]

The idea of optimization is not only in saving space but in the speed too.

Currently Aurora scans TUs every time you start it. I propose to do that only if you go to TU settings of the Title. If multiple renamed TUs in the same folder make the problem then you can creatre TU subfolder there and put that stuff there.

TU handling in Aurora goes from FSD times and IMHO it needs to be changed these days.

[gavin_darkglider 1562]

Your point has been made. The fact is it is not going to change. Also, should be mentioned, that if you read through the other thread from the beginning that MaesterRowen also commented in that thread, and explained the process. When it was mentioned then it wasnt changed. Bring it up again, and I will ban you. Your opinion has been heard, you think it is dated, because you feel the method wastes space, and slows the game launch process. To do what you are asking, we would have to either rewrite a huge section of working code, to appease you, or add to the code, to give you an option to handle it yourself, which makes the code base more complicated, and the XEX bigger. Due to these sorts of issues, the easter egg has been removed from 0.7b already, to make smaller releases, with more useful features. Felida already gave you an option, since you dont like the current way of doing things. Remove your internal HDD, start aurora from the external, turn off TU caching, put your hdd back in your console, and then scan your paths. Though, if you do this, your TUs will get erased when you launch games. To appease you, one of 2 users who have mentioned this out of the thousand or so users currently using aurora, this is a lot of work, and most likely wont happen. Maybe you should go read that other thread from the beginning, where the developers already commented on all of these ideas in 2014. If you read that, you would know that the TU's in Cache, and Content folder get erased when aurora scans, and it copies them back on game startup if they are enabled. So in that sense it does not use double the space, as they are deleted from outside of aurora(Content/Cache) every time aurora reboots, unless the db has them set to enabled. So your waste of space issue is not an issue. As far as using your HDD for live also(sometimes) it has always been recommended that you use a different hdd for live. That being said, this thread is now locked.